On Mon, 15.11.10 16:50, Ludwig Nussel ([email protected]) 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 [email protected] 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
