A Weird Imagination

Status of long-running copy

The problem#

When running an incremental backup with rsync with the --progress flag, it often spends lot of time outputting nothing as it scans through many unchanged files. If you think of it before starting the transfer, --info=progress2 or the name2/skip2 --info flags would give more detail, but once the transfer has been going for a while, you probably don't want to cancel and restart it so you can add those flags.

The solution#

The documentation and this StackExchange answer say you can send a SIGVTALRM signal to rsync version 3.2.0+ and it will output its current progress, but that wasn't working for me.

As a workaround, you can use strace to get a running log of which files rsync is looking at, which includes files it skips without actually opening:

strace --attach="$(pidof rsync)" --trace=openat

(If that's not showing anything, try removing the --trace=openat filter and seeing if there's other syscalls with paths to filter on.)

Alternatively, this StackExchange answer suggests a way to see the currently open files including their sizes (including directories but not unchanged files being inspected):

watch lsof -p"$(pidof rsync | tr ' ' ',')"

(The same should work for a recursive cp/mv/rm.)

Similarly, for getting the status of a transfer of a single large file, this answer attempts to read the files cp is reading/writing to give a running percentage of how much it has copied; a similar approach might work for rsync.

The details#

Read more…

Rarely drawing screen in SDL

The problem#

Working on the same screensaver as yesterday, we want to minimize CPU usage. Since the screensaver is a clock showing hours and minutes, there's no need to do anything except once a minute to change the time display. Optimally, the process would only be scheduled once a minute, exactly when the minute changed, to draw the screen.

Read more…

SDL screensaver hangs on exit

The problem#

I was modifying a screensaver written using SDL and noticed that sometimes there were many instances of it left running, even after unlocking the screen. Another bug was causing the screensaver to use 100% CPU, resulting in it using up all of my processing power just for a simple screensaver.

The solution#

Make the program exit immediately when it receives a SIGTERM signal by including the function

void exitImmediately(int sig) {

and making the SIGTERM signal handler call it:

signal(SIGTERM, exitImmediately);

Read more…