[systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
matt.hoosier at gmail.com
Wed May 6 07:28:47 PDT 2015
One final question on this topic:
I'm not sure from the available discussion of the 'Alias=' directive in
systemd.unit(5) whether it might be possible for me to have two units:
such that clients always phrase their dependencies in terms of the aliased
name ("the-service.service"). At startup time, the virtual unit name would
always happen to be satisfied by dummy-adopted-service.service, but any
subsequent restarts would be accomplished by systemd noticing that
real-service.service exists and using it in preference over
My gut feeling is that this approach doesn't play well with the way that
'systemctl enable' wants to place alias symlinks into /etc/systemd/system/.
I.e., I think that systemd will only ever recognize one provider of the
virtual/aliased service name.
Am I wrong in that assessment in the preceding paragraph?
On Mon, Apr 20, 2015 at 12:49 PM, Lennart Poettering <lennart at poettering.net
> On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoosier at gmail.com) wrote:
> > > > inexperienced poking around the internal default suite of units
> > > > with systemd.
> > >
> > > This is not available, though often requested. But I doubt this can
> > > ever work, since "running before 'everything'" or "running after
> > > 'everything'" is not particularly usefully defined as this all breaks
> > > down as soon as you have two services that want to be run like this
> > Okay, I appreciate that there's no built-in meta-unit that would permit
> > to say "start me to the exclusion of absolutely everything else." I agree
> > that would fail the "what if two processes each tried to play that game?"
> > test.
> > I was just hoping that some unit exists that is synonymous with "the
> > upon which all traditional systemd work is dependent." I suppose nothing
> > still exists matching that kind of weaker description? E.g., ".slice" or
> > something like that.
> You could order yourself before "local-fs-pre.target" plus the various
> early-boot services we ship. That list is pretty limited and
> relatively stable, but there's nothing nicer currently, no.
> Lennart Poettering, Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the systemd-devel