mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

2 bugs involving new stalldetection feature

Browse source
This commit is contained in:
Joey Hess 2020-12-10 17:46:58 -04:00
parent cedad7b37d
commit d3c11eac5d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 34 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
doc/todo/ctrl_c_propagation_to_transferrer_process.mdwn Normal file
View file

@ -0,0 +1,23 @@
When annex.stalldetection is set, and git-annex transferrer is used,
a ctrl-c does not propagate to the transferrer process.
The result is that, the next time the process sends a message to its output
handle (eg a progress update), it gets a SIGINT, and so an ugly message is
output to the console, after the user was returned to the prompt.
The SIGINT is not propagated because a child process group is used for
git-annex transferrer, in order to let child processes of it be killed
along with it when a stall is detected.
Maybe what's needed is a SIGINT handler in the main git-annex that
signals all the transferrer processes with SIGINT and waits on them
exiting. Unsure if that can be implemented in haskell?
Or, note that it would suffice to remove the child process group stuff,
if we assume that all child processes started by git-annex transferrer are
talking to a pipe, and will output something, eg a progress update,
and so receive a SIGPIPE once the transferrer process has caught the
SIGINT and exited.
[[todo/stalldetection_does_not_work_for_rsync_and_gcrypt]] would be a
prereq for this approach. But, might there be long-running child processes
that are not on a pipe, and that need to be shutdown on a stall, too?

11
doc/todo/stalldetection_does_not_work_for_rsync_and_gcrypt.mdwn Normal file
View file

@ -0,0 +1,11 @@
When annex.stalldetection is set, rsync and gcrypt
special remotes do not display any progress. Also, the stall detection
cannot detect stalls, because that needs progress information to do.
These remotes have `displayProgress = False`, and seem to be the only
affected ones.
It seems like it would be a good idea to make these remotes capture the
output of the program they run, and convert it to a progress meter.
(Also, these don't have progress output with -J either..)