[systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Matt Hoosier]

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:

  /lib/systemd/system/dummy-adopted-service.service
    ...
    [Unit]
    DefaultDependencies=no

    [Service]
    Type=forking
    PIDFile=/var/run/already-forked-process.pid
    ExecStart=/bin/true

    [Install]
    Alias=the-service.service
    Wanted-By=sysinit.target

  /lib/systemd/system/real-service.service
    ...
    [Install]
    Alias=the-service.service

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
dummy-adopted-service.service.

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
> wrote:

> On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoosier at gmail.com) wrote:
>
> > > > inexperienced poking around the internal default suite of units
> packaged
> > > > 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
> me
> > 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
> point
> > 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
>
> --
> Lennart Poettering, Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150506/93fcede6/attachment.html>