10

I've just started using lftp for remote transferring files on my Raspberry Pi running Debian. I know how to transfer the files, and use queue and jobs to add and view transferring files.

However, I'm not actually sure on how to view these transfers once lftp moves to the background. The lftp man page mentions how lftp is moving to the background, but when I open a new instance of the program from shell and type jobs, the queue is empty. However, I can clearly see using my file manager that the transfers are still happening, as the files are there and growing in size.

I'm guessing that when I reopen lftp, it's just opening a new instance that isn't connected to the nohup mode lftp that has the active queue. I've tried searching various places, but no one else seems to have this particular issue.

So, I guess what I'm asking is twofold:

  1. Is there a way to easily attach to the background lftp process to view the current jobs list?

  2. If not, is there a way to view this at all?

Improve this question

4 Answers 4

Reset to default
15

You are correct that instances of lftp do not share the job queue, which is of course similar to how shell job queue works.

Still, lftp can indeed attach to an existing backgrounded session. According to lftp news version history, the feature was introduced in version 4.3.0 (2011-06-17). If your connection to lftp session disconnects or you exit with backgrounded transfers ongoing, with recent versions you can still resume the backgrounded lftp process and get access to its job queue.

From lftp man page:

attach [PID]

Attach the terminal to specified backgrounded lftp process.

To do this you need to know the process id, PID, of the backgrounded lftp process. A simple way to do this is the pgrep command, which lists matching process IDs.

For example, here I background a transfer in lftp:

lftp remote:/path> get oi-dev-151a-x86.iso 
[0] get oi-dev-151a-x86.iso &                                             
     `oi-dev-151a-x86.iso' at 655360 (0%) 296.1K/s eta:46m [Receiving data]
lftp remote:/path> exit
[82106] Moving to background to complete transfers...

This lists the pid needed to attach, but in case we did not have this noted down, we can find it again with pgrep:

$ pgrep lftp
82106

And here we resume the backgrounded lftp:

$ lftp
lftp :~> attach 82106
[82106] Attached to terminal.
lftp remote:/path> jobs
[0] get oi-dev-151a-x86.iso 
    `oi-dev-151a-x86.iso' at 42827776 (5%) 1.49M/s eta:10m [Receiving data]

The Debian stable version might not have the attach feature though, but you can still list the active lftp processes with pgrep.

Improve this answer
2
  • This is absolutely correct, though I'm very late commenting on that fact. Thank you very much. For those that come along later, pgrep actually did not work for me. I had to use "ps aux | grep lftp", as (for some reason) pgrep would sometimes not return a value when lftp was certainly running and found with ps aux.
    – drpfenderson
    Commented Jul 12, 2014 at 20:42
  • 1
    If parallel chunk downloads were initiated aka pget, then you can simply cat the file it generates (stored next to the actual file) to see the seek positions. Not very helpful, but gives you an indication.
    – Mohnish
    Commented Nov 10, 2018 at 23:49
1

From the lftp man page:

If  you exit lftp when some jobs are not finished yet, lftp will move itself to
nohup mode in background. The same happens when you have a real modem hangup or
when you close an xterm.

You cannot connect to background processes running with nohup if the parent process has terminated.

Improve this answer
0
1

Collected from the lftp man page: Use ctrl-z to move the process in background and exit lftp, later start lftp again and type wait.

Improve this answer
1
  • As mentioned above, if you exit lftp, it is possible to find PID of the running lftp process (pgrep lftp), then run lftp again, then do attach <PID>, then wait and so on.
    – Milan Kerslager
    Commented May 2, 2020 at 20:39
0

I am on stable Debian.

After my computer entered sleep mode, I started it again and I had to reconnect to ssh, then I navigated to the local dir with cd, then login to external server via lftp and go to remote dir and run the same command I used from the start to initiate the mirroring.

mirror -c --parallel=10

This resumed the previous transfer.

I am still mad at myself for not running it in screen from the start. That is what I would recommend to anyone else. Run all shit like this in screen so you don't have to worry about being disconnected etc.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .