Bug#375061: interrupting unison leaves process on remote machine
Hello, On Fri, Jun 23, 2006 at 03:11:18AM +0200, martin f krafft wrote: Package: unison Version: 2.13.16-5 Severity: normal the subject says it all... I was thinking that the remote process will finish dying by itself !!! (SIGPIPE or something similar). What about creating a sort of heartbeat to check that remote and local process are still alive ? (IE you send at regular interval a packet of data, if one of the process is dead, it cause a SIGPIPE). Kind regard Sylvain Le Gall ps: could you give me more detailed hint on how to reproduce it (if there is more detail to have) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375061: interrupting unison leaves process on remote machine
also sprach Sylvain Le Gall [EMAIL PROTECTED] [2006.06.23.0813 +0200]: I was thinking that the remote process will finish dying by itself !!! (SIGPIPE or something similar). It does not, at least not here. It will continue scanning the filesystem and die some time later. What about creating a sort of heartbeat to check that remote and local process are still alive ? (IE you send at regular interval a packet of data, if one of the process is dead, it cause a SIGPIPE). Well, I'd say it should be fine to send a signal when one process receives a TERM/INT/whatever signal. This should be enough for the other side. ps: could you give me more detailed hint on how to reproduce it (if there is more detail to have) You do need to wait until it's waiting for changes from the other server. I just fire up a unison process and kill it. The two machines are piper [local] and lapse: piper:~ screen -d -m unison piper-lapse ; sleep 5 ; killall -INT unison ; \ ps u -C unison; ssh lapse ps u -C unison USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND madduck 21432 67.0 1.8 41644 35588 pts/15 Rs+ 10:53 0:00 unison -server It's definitely not easy to reproduce, but quite possible. But it seems to only happen when we're waiting for changes from server, and unison *does* die on the remote side when it's done chugging. It would be polite to let it know that it can stop molesting the disk. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP)
Bug#375061: interrupting unison leaves process on remote machine
Hello, martin f krafft writes: also sprach Sylvain Le Gall [EMAIL PROTECTED] [2006.06.23.0813 +0200]: I was thinking that the remote process will finish dying by itself !!! (SIGPIPE or something similar). It does not, at least not here. It will continue scanning the filesystem and die some time later. What about creating a sort of heartbeat to check that remote and local process are still alive ? (IE you send at regular interval a packet of data, if one of the process is dead, it cause a SIGPIPE). Well, I'd say it should be fine to send a signal when one process receives a TERM/INT/whatever signal. This should be enough for the other side. Humm, i don't think it is possible to send a signal on every possible case when unison died... It is better that each living unison check that the other unison is still alive... For example, i don't think it is possible to do anything after : - having received a sig KILL or SEGV, - a computer powerdown ;-) ps: could you give me more detailed hint on how to reproduce it (if there is more detail to have) You do need to wait until it's waiting for changes from the other server. I just fire up a unison process and kill it. The two machines are piper [local] and lapse: piper:~ screen -d -m unison piper-lapse ; sleep 5 ; killall -INT unison ; \ ps u -C unison; ssh lapse ps u -C unison USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND madduck 21432 67.0 1.8 41644 35588 pts/15 Rs+ 10:53 0:00 unison -server It's definitely not easy to reproduce, but quite possible. But it seems to only happen when we're waiting for changes from server, and unison *does* die on the remote side when it's done chugging. It would be polite to let it know that it can stop molesting the disk Humm, OK. I see the case you are describing. Well, i am not sure upstream unison author will accept this, because it doesn't involve real data corruption or something like that... I will try to contact them to have this done, but it is not sure, they will ever try to solve this bug. Kind regard Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375061: interrupting unison leaves process on remote machine
also sprach [EMAIL PROTECTED] [EMAIL PROTECTED] [2006.06.23.1136 +0200]: Humm, i don't think it is possible to send a signal on every possible case when unison died... We're not assuming it'll die. I am only talking about a maintainer-invoked interrupt. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP)
Bug#375061: interrupting unison leaves process on remote machine
Package: unison Version: 2.13.16-5 Severity: normal the subject says it all... -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries Versions of packages unison recommends: ii openssh-client [ssh-client] 1:4.3p2-2 Secure shell client, an rlogin/rsh -- no debconf information -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP)
