<div dir="ltr"><span style="font-size:12.8000001907349px">One final question on this topic:</span><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">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:</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">  /lib/systemd/system/dummy-adopted-service.service</div><div style="font-size:12.8000001907349px">    ...</div><div style="font-size:12.8000001907349px">    [Unit]</div><div style="font-size:12.8000001907349px">    DefaultDependencies=no</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">    [Service]</div><div style="font-size:12.8000001907349px">    Type=forking</div><div style="font-size:12.8000001907349px">    PIDFile=/var/run/already-forked-process.pid</div><div style="font-size:12.8000001907349px">    ExecStart=/bin/true</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">    [Install]</div><div style="font-size:12.8000001907349px">    Alias=the-service.service</div><div style="font-size:12.8000001907349px">    Wanted-By=sysinit.target</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">  /lib/systemd/system/real-service.service</div><div style="font-size:12.8000001907349px">    ...</div><div style="font-size:12.8000001907349px">    [Install]</div><div style="font-size:12.8000001907349px">    Alias=the-service.service</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">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.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">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.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Am I wrong in that assessment in the preceding paragraph?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 20, 2015 at 12:49 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 20.04.15 12:12, Matt Hoosier (<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>) wrote:<br>
<br>
> > > inexperienced poking around the internal default suite of units packaged<br>
> > > with systemd.<br>
> ><br>
> > This is not available, though often requested. But I doubt this can<br>
> > ever work, since "running before 'everything'" or "running after<br>
> > 'everything'" is not particularly usefully defined as this all breaks<br>
> > down as soon as you have two services that want to be run like this<br>
><br>
><br>
> Okay, I appreciate that there's no built-in meta-unit that would permit me<br>
> to say "start me to the exclusion of absolutely everything else." I agree<br>
> that would fail the "what if two processes each tried to play that game?"<br>
> test.<br>
><br>
> I was just hoping that some unit exists that is synonymous with "the point<br>
> upon which all traditional systemd work is dependent." I suppose nothing<br>
> still exists matching that kind of weaker description? E.g., ".slice" or<br>
> something like that.<br>
<br>
</span>You could order yourself before "local-fs-pre.target" plus the various<br>
early-boot services we ship. That list is pretty limited and<br>
relatively stable, but there's nothing nicer currently, no.<br>
<div class="HOEnZb"><div class="h5"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</div></div></blockquote></div><br></div>