[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

All services that require a restart from libc6 upgrade...

Ok, I'm tired of having to track all services that might need to be
restarted after a libc6 upgrade. So here's what I am going to do. I want
to require all packages that need this to declare a new reply in it's init
script. It's very simple, I check your init script like this:

check=$(/etc/init.d/service nss-check 2>&1 || true)

if [ "$check" = "restart" ]; then
	# this service needs to be restarted

So all you need is an extra option in your init script to handle this.
Something like

case $1 in
	<other options>

		echo restart
		exit 0

This way I don't have to keep a static list that is usually incomplete and
wrong. I'd like this ammended to policy with something like:

	Some daemons can be affected by libc upgrades. This usually
	happens if the daemon uses functions related to NSS (username,
	group, hostname and other name lookups). Because these functions
	rely on loading modules (libnss_*.so) that may not match the
	current libc mapped in memory with the program, it may need to be
	restarted when libc is upgraded. The libc package takes care of when
	this needs to occur, but your daemon will need to tell libc that
	it needs to be restarted in this case.

	This is handled in the init.d script (see the section about
	init.d). In addition to the other options that the init.d script
	needs to handle, it also needs to check for "nss-check" and return
	"restart" in this case.

I'd like to see this taken care of fairly quickly, so it can be
implemented in woody now, and so I don't get anymore bug reports about
"service 'foo' also needs to be restart".

The only problem I forsee is that some init.d scripts execute regardless
of the options passed to it. IMO, this needs to be specifically forbidden
atleast in runlevels 2-5.


/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '

Attachment: pgpkaP22L5w4t.pgp
Description: PGP signature

Reply to: