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 %MEM VSZ RSS TTY STAT START TIME COMMAND
USER PID %CPU %MEM VSZ 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]
