[systemd-devel] getty at .service.m4 and serial-getty at .service.m4

[Kay Sievers]

On Thu, Nov 11, 2010 at 20:08, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 11.11.10 12:50, Kay Sievers (kay.sievers at vrfy.org) wrote:
>
>> > Anyway, the point of this was only to have getty start late(ish) in
>> > the boot process, after most of the other services that are pulled in
>> > by multi-user.target. Maybe there is a better way to specify this, if
>> > not everyone has rc.local?
>>
>> Yeah, others asked for that too. So far, we don't really have a
>> concept of 'late' or 'last' in systemd.
>
> I don't think such a concept would even make sense. If you order more
> than once service as "last", then how would they ordered against
> each other?
>
> We already have something remotely similar: if you want stuff to be run
> after multi-user.target is reached (instead of 'before') then you can
> just add an After=multi-user.target into the unit files. By default all
> services pulled in from multi-user.target via Wants= or .wants/ will
> implicitly gain a Before=multi-user.target, which however is disabled if
> you by hand add After=multi-user.target instead. That said, I do believe
> that using this is really a bad idea and people should instead really
> sort their stuff after the services they really mean. Placeholders for
> "everything" is just a dead-end.

I know, and it really can't work.

It's the same as scsi_wait_scan, udev settle, vgscan, ..., and all
this stuff that does no longer fit into the reality we have to deal
with. We can't get that right, and ideally everything that wants to
survive todays setups, should be hotplug aware.

There might be some inconveniences caused by not trying to provide
such stuff in systemd, and it might make things hard for stuff that is
making any such assumptions, but we should try to get stuff right now,
fix what we can, and stop pretending to know things we really don't
know.

Kay