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

[Ludwig Nussel]

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?

> > > The big problem here is that there isn't really a well defined point in
> > > time anymore where bootup is finished.
> > 
> > If such a point in time doesn't exist, what does the "Startup
> > finished" message from systemd mean then? :-)
> 
> 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.

> > > In traditionally sysvinit startup
> > > messages were only printed on the console for proper sysv services and
> > > only when started at boot time. However, in the much more dynamic
> > > systemd we print them for all services (including D-Bus services, which
> > > actually account for more services than SysV on most setups right
> > > now). The effect of that is that services come all the time and there's
> > > little point in synchronizing getty startup to that.
> > 
> > There is also little point in starting a getty on tty1 as long as
> > script output floods the console so the prompt scrolls away anyways.
> 
> 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.

cu
Ludwig

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