starting avahi with runit

[rasker]

Well, I hope someone can help me here.

I have a project going that switches services from running through the normal init process to using runit (parallel startup, service supervision and all that malarky).

It's all going swimingly apart from a couple of weird issues with avahi. BTW this is on fully updated fedora 8.

Just a little background: runit requires daemons to be run in the foreground using exec. So the daemon *has* to inherit the pid from the shell it was executed in (this facilitates service supervision). To solve various issues in the real world a small helper app called chpst (change process state) is included. You can change various things like user and group, nice level, closing the shells i/o before executing the daemons and such like. What this means is that avahi can't be started using the -D option.

I believe avahi on fedora runs in a chroot. so starting it with just 'exec avahi-daemon' fails in a runit environment as avahi exits complaining about not finding it's process and runit also loses track of the process ID.

running avahi with the following command line:

exec chpst -u avahi:avahi avahi-daemon (setting the user to avahi and the group to avahi)

fails as avahi complains about needing to be run as root.

running avahi with the following command line:

exec chpst -u root:avahi avahi-daemon (setting the user to root and the group to root)

succeeds but runit loses the process and tries to restart it (over and over and over ....... again).

running avahi with :

exec avahi-daemon (setting the user to root and the group to root)

This continues with all the various options (running as user avahi and group avahi with the --no-drop-rrot options and such like).

The only time avahi runs correctly is if the -s option is used. e.g.

exec avahi-daemon -s (runs properly with a subprocess of chroot helper, meaning it has been run as root and dropped root priveledges and scoots off running as avahi user+group in a chroot which I think is the expected behaviour.)

In fact, avahi runs well launching with exec with many of the options as long as the -s option is given.

Running avahi-daemon from a console using exec seems to work normally (i.e. it runs ok and is in what looks like a normal state, chrooted).

This doesn't really make any sense to me. In fact on face value it's kinda weird. Outputting to syslog should not really affect how a daemon sets up it's processes or runs on a system or does anything. Spitting messages out to stderr or to syslog should be the same. no? Also running the same commands that fail from a script work from a console (logged in as root).

Anyway I thought I should report this odd behaviour. Please don't change anything because it's taken me ages to get this working :)

On the other hand if you do fix anything could you also test it with being launched with exec from a shell script? It would be nice to get this working with stderr as I could then have this service not only supervised and restarted if dependancies are restarted but have it's own individual log file (the svlogd logging app that comes with runit captures stdio).

[rasker]

I have given this some more thought and I think I can summarise the above (yup, you heard that right):

When avahi-daemon runs in forground mode it either detaches from the shell it ran from or it forks. If the -s option is used it doesn't detach from the shell it came from or it doesn't fork.

If the code to do this is python based it might be a case of using the same exec() function (exec() in the same shell if running in foreground mode) for all these cases and especially not using the fork () function/method/whatever it's called in forground mode. Most likely it is execing in a different shell (still in foreground mode) but this behaviour causes problems for init replacements that need daemons to stay in the same shell/process it was starting in.

If only I had said this in the first place....

Cheers R

[lennart]

I am not sure why you would want to run Avahi with something like "chpst". Avahi is able to drop priviliges by itself, and needs to do that in the proper order -- i.e. after chrooting, so this *has* do be done by Avahi, and not by some external program.

The thing about process monitors like runit is that they are unable to detect when daemon startup is complete. Well written daemons (and Avahi is one of those) wait until the daemon is fully initialized before detaching from the calling terminal. If you don't let Avahi fork, then there is no way that the startup scripts are notified about completed initialization. However, that is necessary to allow startup of all services depending on Avahi at the right time.

You didn't write what exactly the problem with calling "avahi-daemon" without any arguments is?

Your followup totally confuses me.

Puzzled, Lennart

[lennart]

No followup in 3 months, closing.