Bug#694048: havoc and distruption ^_^

2013-02-12 Thread Salvo Tomaselli
Hello, I am really sorry, I applied the patch a long time ago and forgot to report back to you. Then forgot about it, then removed systemd and went back to systemV. Well i have not encountered problems. Still this doesn't fix the race condition in start-stop-daemon, but I guess it does enough

Bug#694048: havoc and distruption ^_^

2013-02-04 Thread Michael Biebl
On 18.01.2013 22:58, Michael Biebl wrote: > Hi Salvo, > > On 03.12.2012 11:05, Tollef Fog Heen wrote: >> Then one should use --retry. s-s-d supports the behaviour you're >> describing. > > Could you please try the attached patch for the fetchmail sysv init > script and let us know if that fixes

Bug#694048: havoc and distruption ^_^

2013-01-18 Thread Michael Biebl
Hi Salvo, On 03.12.2012 11:05, Tollef Fog Heen wrote: > Then one should use --retry. s-s-d supports the behaviour you're > describing. Could you please try the attached patch for the fetchmail sysv init script and let us know if that fixes your problem. Michael -- Why is it that all of the

Bug#694048: havoc and distruption ^_^

2012-12-04 Thread Michael Biebl
On 02.12.2012 22:11, Michael Biebl wrote: > On 02.12.2012 22:04, Salvo Tomaselli wrote: >> >>> if start-stop-daemon -K --retry=TERM/30/KILL/5 -o -q -p $PIDFILE -x >>> $DAEMON -u $USER; then >> Okay, it seems to be working now, but also seemed to be working in general, >> the problem doesn't occur

Bug#694048: havoc and distruption ^_^

2012-12-03 Thread Tollef Fog Heen
]] Salvo Tomaselli > Start-stop-daemon terminates when the signal has been sent, not when the > process has terminated, waiting for the process to terminate would make the > scripts easier. > After all they are trying to stop a daemon not to send a signal, so they are > interested in the effe

Bug#694048: havoc and distruption ^_^

2012-12-02 Thread Salvo Tomaselli
> Some explanation why you see different behaviour between sysvinit and > systemd: > systemd internally translates "restart" to "stop + start", i.e. it calls > /etc/init.d/foo stop && /etc/init.d/foo start. > That's why the "sleep 1" hack is only active under sysvinit. > I bet, if you removed the

Bug#694048: havoc and distruption ^_^

2012-12-02 Thread Michael Biebl
On 02.12.2012 22:04, Salvo Tomaselli wrote: > >> if start-stop-daemon -K --retry=TERM/30/KILL/5 -o -q -p $PIDFILE -x >> $DAEMON -u $USER; then > Okay, it seems to be working now, but also seemed to be working in general, > the problem doesn't occur every time... that's the nature of race conditi

Bug#694048: havoc and distruption ^_^

2012-12-02 Thread Salvo Tomaselli
> if start-stop-daemon -K --retry=TERM/30/KILL/5 -o -q -p $PIDFILE -x > $DAEMON -u $USER; then Okay, it seems to be working now, but also seemed to be working in general, the problem doesn't occur every time... > Fwiw, the sleep 1 in restart) looks like on of those dirty hacks to > workaround ra

Bug#694048: havoc and distruption ^_^

2012-12-02 Thread Michael Biebl
On 02.12.2012 20:59, Salvo Tomaselli wrote: > I did as you asked in the /etc/init.d/fetchmail script and when i do a > restart, in the log nothing appears. > > If i do > #service fetchmail stop, after the change i have this: > fetchmail.service - LSB: init-Script for system wide fetchmail daemon

Bug#694048: havoc and distruption ^_^

2012-12-02 Thread Salvo Tomaselli
I did as you asked in the /etc/init.d/fetchmail script and when i do a restart, in the log nothing appears. If i do #service fetchmail stop, after the change i have this: fetchmail.service - LSB: init-Script for system wide fetchmail daemon Loaded: loaded (/etc/init.d/fetchmail)