On Sat, 09.07.11 23:31, Steve Dickson (SteveD@xxxxxxxxxx) wrote: > On 07/08/2011 10:57 AM, Michal Schmidt wrote: > > On 07/08/2011 03:57 PM, Steve Dickson wrote: > >> On 07/08/2011 08:23 AM, Lennart Poettering wrote: > >>> So, I'd suggest strongly not to try starting all services from a single > >>> file. There's a reason why we explicitly forbid having more than one > >>> ExecStart= in a unit file (except for Type=oneshot services). > >> Thank you for this explanation. It appears your definition of a > >> service might be a bit too simple for many subsystems. You seem > >> to think that on service will only start one system daemon, which > >> is not the case in the more complex subsystems. > > > > Each of the daemons can have its own unit file. We don't have to map the > > old initscripts to systemd units 1:1. > > So one service can not have multiple daemons? As mentioned earlier, it can, but we strongly advise you not to do this, since it makes it hard to supervise and monitor a service, to restart it when it crashes, to collect exit statusses, to run other services on failure, to match up log messages, to even inform the user about most basic service status. We support this for compat with SysV, not as a feature you should actually use. > > This must be some misunderstanding, or you're seeing an unusual bug. > > It just cannot happen. The second ExecStartPre of the unit is run after > > the first one exits, not earlier. > > Or do you mean synchronization among several units? Then you want to > > specify ordering dependencies (Before, After). > > Please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=699040#c35 > It sure looks like one process is being started for another one ends... If you want to know the precise runtime of a process systemd started, then use "systemctl show" on the service which will show you a lot of additional low-level data for a service, and timestamps for each processes are included. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
