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

[Lennart Poettering]

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.

> > Only Fedora and Arch have rc.local. If you ask me rc.local is something
> > that should just die, hence I am very reluctant to support it on any
> > more distros than we currently support it on.
> 
> On SUSE we have boot.local (executed after boot.d scripts),
> before.local (before runlevel switch) and after.local (when runlevel
> reached) ... The latter two are just less widely known as there is
> no empty stub script for them.

Maybe this is a chance to deprecate before.local and after.local, since
they actually make little sense in a systemd world where runlevels
retain little meaning.

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

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.