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

[Ludwig Nussel]

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

That method still works if serial-getty at .service is a link though.
IOW util-linux could install it as link to serial-agetty at .service
without breaking the feature.

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

As Andrey already wrote a daemon that forks before it's ready is
a bug and breaks sysv booting as well.

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

How many services run After=multi-user.target? You said it's bad to
do that so there shouldn't be any. Getty could be declared the
official exception from the rule.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)