Signal to make rclone output an extra line of current progress

I've redirected the stdout and stderr to file for a long-running rclone cryptcheck process. But the logs have stopped growing many hours ago (new lines were coming in every 15 minutes before).

I'm wondering if there's a way to send a signal (I know SIGHUP already has a use; so maybe SIGUSR1?) to force rclone to spit out its current status. That way I can make a judgment call whether to kill the process and restart.

2024/02/12 21:30:48 NOTICE: 2024/02/12 21:30:48 -           0 B / 0 B, -, 0 B/s, ETA -
2024/02/12 21:45:48 NOTICE: 2024/02/12 21:45:48 -           0 B / 0 B, -, 0 B/s, ETA -
2024/02/12 22:00:48 NOTICE: 2024/02/12 22:00:48 -           0 B / 0 B, -, 0 B/s, ETA -
2024/02/12 22:15:48 NOTICE: 2024/02/12 22:15:48 -           0 B / 0 B, -, 0 B/s, ETA -
[nothing for 5 hours]

There is a lot to unpack there.

What version?
What cloud remote?
What command did you run?
How many files? Size?

Oh I'm not trying to diagnose the root cause.

I'm asking for a feature to just make rclone output the current status (and not have to wait until the next line of progress). This would be helpful regardless of this current issue I'm having

Without knowing your setup, it's tough to offer any advice though, so we're at a catch 22 then if you aren't able to help.

I'm not sure if you understand my feature request. I'm not asking for advice. I'm making a feature request.

I want rclone to respond to a SIGUSR1 by outputing a progress line such as:

2024/02/13 01:20:01 NOTICE: 2024/02/13 01:20:01 -           0 B / 0 B, -, 0 B/s, ETA -

where 01:20:01 is right now.
That way I don't have to wait 15 minutes for the next progress output line.

I fully understand that, but what I am asking is your verison and config and setup to understand why it's not showing up or what the issue might be.

^^^

So putting in a signal is a work around as we don't understand what the problem is.

Ah ok.
The reason I wasn't ready to go there is that I wasn't sure it was rclone's fault as I was messing around with the logfiles and it's very possible that I broke the link between the logfile and rclone by possibly moving the logfile. I wanted to try again before filing a definitive bug report.

In any case, here's the info:

  • macOS 13.6.4 (Ventura) MacBookPro18,2 (ARM64)
  • Installed rclone from MacPorts:
❯ /opt/local/bin/rclone --version
rclone v1.65.2
- os/version: darwin 13.6.4 (64 bit)
- os/kernel: 22.6.0 (arm64)
- os/type: darwin
- os/arch: arm64 (ARMv8 compatible)
- go/version: go1.21.6
- go/linking: dynamic
- go/tags: cmount noselfupdate
  • BackBlaze B2
  • Command: time -h -a -o /Users/rcowboy/Library/Logs/rcowboy/bak.MobileSync.log nice -n 15 /opt/local/bin/rclone cryptcheck /Volumes/MyDrive/MobileSync/ b2-mac-backup-secret:MobileSync --exclude=/+mac/git/**
  • 251.6GB 589099 items

I would think moving the log file would break the log.

Possibly.

But back to the original feature request…

To show that my feature request has little to do with my particular log issue and has broad utility, here's precedent for SIGUSR1 to show current status:

Manual — restic 0.16.4 documentation.

Additionally, on Unix systems if restic receives a SIGUSR1 signal the current progress will be written to the standard output so you can check up on the status at will.

https://man7.org/linux/man-pages/man1/dd.1.html

Sending a USR1 signal to a running 'dd' process makes it print I/O statistics to standard error and then resume copying.

More apps also implement the same convention.

I hope you can see how useful this feature would be.

Possible workaround here: if you add --rc to the command, then in a new terminal process you can run:

rclone rc core/stats

at any time to see the current stats.

2 Likes

If you move the log and break the link to rclone writing the log, your feature request does nothing as the log file isn't connected and won't be updated....

I didn't say that I moved the log. I said it's very possible that I moved the log. The point is I don't know what went wrong for sure.

This feature would help narrow down the potential problem. Whether SIGUSR1 succeeded or not in adding an additional line to the logs is exactly the kind of additional info that would be helpful.

If the log stopped updating and you think you moved, that really makes the most sense that it was moved as the log wouldn’t really stop.

Good to know.

I may have several simultaneous rclones. At first glance, it looks like I'd have to make sure they're on separate ports, right?

That is one option. Another option is to run multiple _async jobs on the same server. You can still keep each job's stats separate with stats groups.