Lennart Poettering wrote: > On Tue, 16.11.10 09:36, Ludwig Nussel ([email protected]) wrote: > > Lennart Poettering wrote: > > > 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. > > > > That's just a matter of having [email protected] in an > > install section though, isn't it? > > There's some magic in systemd which automatically adds > [email protected] 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 [email protected] is a link though. IOW util-linux could install it as link to [email protected] 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 > > [email protected] 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) _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
