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

[Andrey Borzenkov]

On Wed, Nov 17, 2010 at 1:15 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 16.11.10 09:36, Ludwig Nussel (ludwig.nussel at suse.de) wrote:
>
>>
>> Lennart Poettering wrote:
>> > On Mon, 15.11.10 16:50, Ludwig Nussel (ludwig.nussel at suse.de) wrote:
>> >
>> > > > Fixed this now. Ideally Debian/Ubuntu would stop renaming agetty like
>> > > > this, or at least do it via symlink only. I'd love to get rid of the
>> > > > differences between the distros here.
>> > >
>> > > Why is the (a)getty service file part of systemd anyways? It could
>> > > be in the util-linux package as agetty at .service instead.
>> >
>> > Well, it could be moved there. However, systemd actually has some magic
>> > code in place which autospawn a serial getty on the TTY specified by
>> > console= on the kernel command line. Due to that the getty actually is
>> > special, the same way es tty handling is special in the kernel.
>>
>> That's just a matter of having Alias=serial-getty at .service in an
>> install section though, isn't it?
>
> There's some magic in systemd which automatically adds
> serial-getty at ttyS0.service if "console=ttyS0" (or suchlike, for whatever
> tty) appears on the kernel cmdline. That more than you can to with naked
> service files.
>
>> > Well, it's the point where systemd for the first time has no queued jobs
>> > anymore. It's similar to udev in this regard, after the "udev settle"
>> > operation finished: by no means this is an indication that every hw has
>> > been found (resp every service been started), it just means, that for
>> > the first time we are kinda idle ourselves.
>>
>> Isn't that close enough to the traditional understanding of a
>> finished boot process? After all reaching e.g. runlevel 5 doesn't
>> mean 'everything' is started either. There could be e.g. cron jobs
>> triggered by @reboot or dbus services starting up due to gdm/auto
>> login of an X session.
>
> Well, the majority of services are nowadays started and not
> synchronized. That means that at that point in time all services might
> be forked off, but not necessarily running.

it is service bug that has to be fixed, not used as excuse to ignore
"I am started" indication. I hit such services every now and then and they
caused grief also without systemd as well.

Systemd has well defined semantic when service is considered started. Let's
deal with broken services when we see them.

And BTW - all this discussion is likely not about messages from *service*,
but about message from *systemd* itself. In this case when service itself
is ready is irrelevant - we are speaking purely about "Starting ..." message
from systemd, which currently overwrite getty prompt.

>                                                               Which still makes this point
> semi-useful for profiling, but useles for synchronizing boot.local or
> $ALL to it.
>
>> > Well, turns out if you start thing in parallel their output will
>> > necessarily be concurrent.
>>
>> Sure. The boot console already looks much better if I add a separate
>> getty at tty1.service file that has After=multi-user.target instead of
>> Before=getty.target though.
>
> But that's luck, and not necessarily so.

This worked surprisingly good in the past 20 years or so :)

>                                                            You are basically racing
> against all the other processes that just got spawned at that time. If
> they manage to put their message on the screen before you, your luck. If
> they end up putting it on the screen after you onyl, then your tough
> luck...
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>