On 07.03.2012 22:46, Steve Langasek wrote: > On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote: > >> It's rather easy to confuse upstart's process tracking. You >> explicitly have to tell upstart if a daemon forks once or twice >> (expect daemon, expect fork) and if the daemon forks multiple >> children upstart often doesn't get it right. > .. > > The use of ptrace for process tracking is ugly, but that has nothing > to do with the need for 'expect daemon' or 'expect fork'. You still > need to have some way of deciding when the service should be > considered *started*, and the rules are going to be different for > each service. I found the process tracking facility in upstart rather brittle sometimes. As said, if you didn't get the expect stanza right, upstart thought the daemon was not running at all. Some daemons had oddities how they forked of child processes which confused upstart so it didn't track the right process, and so on. A common recommendation back then was, to simply not let the daemon fork (most of them provide a -f or equivalent switch). This of course means, the traditional way of signaling that a service is ready to process requests (i.e. after the fork and writing the pid file), doesn't work either anymore. Using cgroups might > make the difference between 'expect fork' and 'expect daemon' > immaterial, but cgroups alone will *not* give you a race-free > startup. systemd says you should avoid races by using socket-based > activation for everything; I'm not convinced this is actually > superior for anything except the desktop case, but in any event it > means you would still get races for anything not (yet) using socket > activation if you don't have some clearer notion of what it means for > a job to be "running". Not true. Supporting socket activation is optional. It's not a pre-condition for a race free startup. That's what the Type stanza [1] is for. > Type= Configures the process start-up type for this service unit. One > of simple, forking, oneshot, dbus, notify. > > If set to simple (the default value) it is expected that the process > configured with ExecStart= is the main process of the service. In > this mode, if the process offers functionality to other processes on > the system its communication channels should be installed before the > daemon is started up (e.g. sockets set up by systemd, via socket > activation), as systemd will immediately proceed starting follow-up > units. > > If set to forking it is expected that the process configured with > ExecStart= will call fork() as part of its start-up. The parent > process is expected to exit when start-up is complete and all > communication channels set up. The child continues to run as the main > daemon process. This is the behaviour of traditional UNIX daemons. If > this setting is used, it is recommended to also use the PIDFile= > option, so that systemd can identify the main process of the daemon. > systemd will proceed starting follow-up units as soon as the parent > process exits. > > Behaviour of oneshot is similar to simple, however it is expected > that the process has to exit before systemd starts follow-up units. > RemainAfterExit= is particularly useful for this type of service. > > Behaviour of dbus is similar to simple, however it is expected that > the daemon acquires a name on the D-Bus bus, as configured by > BusName=. systemd will proceed starting follow-up units after the > D-Bus bus name has been acquired. Service units with this option > configured implicitly gain dependencies on the dbus.socket unit. > > Behaviour of notify is similar to simple, however it is expected that > the daemon sends a notification message via sd_notify(3) or an > equivalent call when it finished starting up. systemd will proceed > starting follow-up units after this notification message has been > sent. If this option is used NotifyAccess= (see below) should be set > to open access to the notification socket provided by systemd. If > NotifyAccess= is not set, it will be implicitly set to main. Especially the dbus type is very neat. I don't think upstart supports something similar like that. Cheers, Michael [1] http://0pointer.de/public/systemd-man/systemd.service.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature