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

[Lennart Poettering]

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. 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. 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.