On Fri, Apr 25, 2008 at 01:38:39PM -0400, Joey Hess wrote:
> AFAIK, start-stop-daemon still defaults to refusing to stop a daemon if
> the executable has changed from the executable it initially started. Ie:
"still defaults" - since when? i've never seen that behaviour.
start-stop-daemon uses pidfiles (e.g. /var/run/dictd) to kill the
running daemon.
> [EMAIL PROTECTED]:/usr/sbin>/etc/init.d/dictd start
> Starting dictionary server: dictd.
your example seems to be specific to dictd, not to all daemons. that
indicates a bug in dictd or in dictd's init.d script, not a general
problem with start-stop-daemon.
i've never seen anything like that problem with other packages that
restart in the postinst.
e.g. one package that the maintainer recently fixed to work around the
bug in dh_installinit is rsyslog.
example one: replace /usr/sbin/rsyslogd by a copy of itself:
ganesh:/usr/sbin# ps aux | grep rsyslogd
root 23408 6.0 0.1 77968 5056 ? Sl 09:48 0:00
/usr/sbin/rsyslogd -c3 -staz.net.au
root 23419 0.0 0.0 5320 748 pts/16 R+ 09:48 0:00 grep rsyslogd
ganesh:/usr/sbin# mv rsyslogd rsyslogd.orig
ganesh:/usr/sbin# cp -af rsyslogd.orig rsyslogd
ganesh:/usr/sbin# invoke-rc.d rsyslog restart
Stopping enhanced syslogd: rsyslogd.
Starting enhanced syslogd: rsyslogd.
ganesh:/usr/sbin# ps aux | grep rsyslogd
root 23471 6.0 0.1 77956 5056 ? Sl 09:48 0:00
/usr/sbin/rsyslogd -c3 -staz.net.au
root 23483 0.0 0.0 5320 748 pts/16 S+ 09:48 0:00 grep rsyslogd
that works. PID of rsyslogd changed from 23408 to 23471. successfully
restarted.
example two: replace rsyslogd with /bin/echo:
NOTE: /bin/echo is a better program to use for this experiment than
/bin/ls because it doesn't complain about args it doesn't
understand and then die with a non-zero exit code.
ganesh:/usr/sbin# cp -af /bin/echo rsyslogd
ganesh:/usr/sbin# invoke-rc.d rsyslog restart
Stopping enhanced syslogd: rsyslogd.
Starting enhanced syslogd: rsyslogd-c3 -staz.net.au
.
ganesh:/usr/sbin# ps aux | grep rsyslogd
root 24486 0.0 0.0 5320 716 pts/16 R+ 09:51 0:00 grep rsyslogd
that also works. you can see the output of /bin/echo on the end of the
"Starting..." line.
example three: move the original rsyslogd back into place
ganesh:/usr/sbin# mv rsyslogd.orig rsyslogd
ganesh:/usr/sbin# invoke-rc.d rsyslog restart
Stopping enhanced syslogd: rsyslogd already stopped.
Starting enhanced syslogd: rsyslogd.
ganesh:/usr/sbin# ps aux | grep rsyslogd
root 24563 0.0 0.1 77968 5076 ? Sl 09:51 0:00
/usr/sbin/rsyslogd -c3 -staz.net.au
root 24927 0.0 0.0 5320 716 pts/16 R+ 09:55 0:00 grep rsyslogd
once again, that works. start-stop-daemon doesn't care that the binary
has changed since it was originally started.
THAT is the typical behaviour of start-stop-daemon during an upgrade.
there are numerous daemons within debian that already work around
dh_installinit's bug in order to do the right thing and restart in the
postinst.
> Therefore if I were to take your advice that this bug is somehow RC, and
> change debhelper as you suggest today, I would in fact completly break
> upgrades of the majority of daemons in Debian.
no, it shows that dictd or the dictd package is already broken in some way.
> dh_installinit -n can be used to ditch debhelper's default init script
> starting code, and put in init script code that is tuned to the particular
> daemon.
it is the exception that requires unusual handling, NOT the general
case.
dictd is an exception, not the rule. it requires special handling (or
bug fixing).
the general case is that daemons can and should continue to work
smoothly during upgrade, do not exhibit stop/start/restart problems
if the daemon binary is changed, and should just be restarted in the
postinst.
the point is that the rsyslog maintainer shouldn't have had to work
around this bug in dh_installinit. he's using the tool to make
package maintainence and conformance to policy/standards easier and
semi-automatic. dh_installinit should do the right thing for the
general, most common, case and still allow manual overrides/workarounds
for special cases.
instead, it currently does the wrong thing for the general case,
handles the exception as if it is the rule, and requires manual
overrides/workarounds to properly handle the general case. i.e. the
reverse of what it should do.
craig
--
craig sanders <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
