I see you like your package buggy. Fair enough.
* Paul Slootman <[email protected]>, 2016-07-12, 16:35:
severity 830866 normal
thanks
This bug does not meet the "serious" requirement, namely:
is a severe violation of Debian policy (roughly, it violates a must
or required directive), or, in the package maintainer's or release
manager's opinion, makes the package unsuitable for release.
In normal use you will not encounter this situation.
I've been reporting bugs to Debian for over a decade. I don't need
lectures about bug severities, thanks.
This bug was filed with severity normal, as it should be.
On Tue 12 Jul 2016, Jakub Wilk wrote:
When I press Ctrl+C, a background rsync process survives, continuing
to clog up my modest Internet connection:
$ rsync -avP
rsync://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/misc/ .
MOTD: Welcome to the rsync archive at Academic Computer Club, Umeå University.
receiving incremental file list
./
DebConf15-Final.mp4
327,680 0% 59.52kB/s 0:11:40 ^C
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(632)
[generator=3.1.1]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(504)
[receiver=3.1.1]
$ pgrep rsync
6251
$ strace -p 6251
strace: Process 6251 attached
_newselect(4, [3], [], [3], {59, 989267}) = 1 (in [3], left {59, 980959})
read(3,
"\3644\212W\272\\\345\371:\371\260\3460;R\361t\240\237\324\245)\n\303\205\26\241.\321p\20\322"...,
1288) = 1288
_newselect(4, [3], [], [3], {60, 0}) = 1 (in [3], left {59, 999995})
read(3,
"\241\3752:=~\337\217\274q\251\25\354\25\260~;s\252\7\220\205\4\227\17{&\222(\304\20\350"...,
31756) = 160
...
The process tells the remote server to abort the connection and waits
for response to that notification. There can be a lot of data in
transit (in buffers en route to you) which will be sent to you anyway
regardless...
Huh...
so aborting the process won't help in any way.
No, killing the process (with SIGTERM) helps almost immediately.
OTOH, if I don't kill it, it runs for many minutes. (I got bored after
10...)
You could try limiting all transfers using --bwlimit to just below the
capability of your internet connection, that way aborting the
connection should be almost direct. This depends however on whether the
server accepts the option.
I doesn't make any difference, at least for this particular server.
--
Jakub Wilk
