Re-opening part of issue #5 hereby, it may indeed be useful.
The idea: get a status of a process running in the background (typically upload or download) by sending it a SIGUSR1 signal.
So:
glacier-cmd is running in the background, merrily pumping data to or from Amazon Glacier.
user sends SIGUSR1 signal to the program (kill -SIGUSR1 <pid>)
glacier-cmd sends back status information (latest progress message should do).
And as we're meddling with signals anyway, I'd suggest to add SIGINT or maybe SIGTERM to this. Sending this signal interrupts upload/download the moment the block currently being handled is finished, providing a graceful way of interrupting a download, short of brutally kill -9ing the thread.
Just now I've done some searching on signals.
Catching a signal seems pretty straightforward, replying to the signal not, if possible at all. I think basically what we want is something like this to happen:
$ kill -SIGUSR <pid_of_glacier-cmd>
Uploading test_archive to test_vault.
Wrote 7.0 MB of 8.0 MB (87%). Rate 73.16 KB/s, average 66.43 KB/s, eta 22:32:12.
The signal catcher can not get the pid of the calling process, only that it is called.
I think the only way around this, is to use some kind of temporary file to communicate back. That is, glacier-cmd will write to a predetermined file (/tmp/glacier-cmd.<pid>.status with 666 permissions sounds suitable to me; no need to worry about Windows because it doesn't do signals to begin with), then the caller can look for this file (say every second), read the data, and delete it. And we should launch a clean-up thread from the main thread that sleeps for say a minute, then deletes the file if it's not removed yet.
So all in all we'd have to write a script, say glacier-cmd-status that checks for running instances of glacier-cmd, sends each of them them an os.kill(pid, signal.SIGUSR1) signal, and then checks for status messages in the respective files.
Comments, please! It's the first time ever I'm looking into signals so I may have missed some obvious bits.
Re-opening part of issue #5 hereby, it may indeed be useful.
The idea: get a status of a process running in the background (typically upload or download) by sending it a SIGUSR1 signal.
So:
kill -SIGUSR1 <pid>
)And as we're meddling with signals anyway, I'd suggest to add SIGINT or maybe SIGTERM to this. Sending this signal interrupts upload/download the moment the block currently being handled is finished, providing a graceful way of interrupting a download, short of brutally
kill -9
ing the thread.Just now I've done some searching on signals. Catching a signal seems pretty straightforward, replying to the signal not, if possible at all. I think basically what we want is something like this to happen:
The signal catcher can not get the pid of the calling process, only that it is called.
I think the only way around this, is to use some kind of temporary file to communicate back. That is, glacier-cmd will write to a predetermined file (
/tmp/glacier-cmd.<pid>.status
with 666 permissions sounds suitable to me; no need to worry about Windows because it doesn't do signals to begin with), then the caller can look for this file (say every second), read the data, and delete it. And we should launch a clean-up thread from the main thread that sleeps for say a minute, then deletes the file if it's not removed yet.So all in all we'd have to write a script, say
glacier-cmd-status
that checks for running instances ofglacier-cmd
, sends each of them them anos.kill(pid, signal.SIGUSR1)
signal, and then checks for status messages in the respective files.Comments, please! It's the first time ever I'm looking into signals so I may have missed some obvious bits.