So wait, there is a way to force getty to come up after everything has initialized with systemd? I'm just lost with this whole switch to systemd and reading the info on it has confused me even more.
I have this aswell, but i think i remember it happen before systemd at some point aswell.
The thing is also, that since some time ago one could write over/delete the characters of the actual prompt (i think that is still the case)
But yeah, this issue is annoying, it only happens sometimes (due to however fast the "services" start) but it is very confusing.
I am a bit worried that many people expect/use a login to X/graphic manager, thus this bug gets too little attention.
I too have a vague recollection of this occuring before systemd as well. But I am not 100% about that...
Honestly, with your concerns about people's exectations, if a non-*nix user is looking at a Linux machine, I don't think they really know what to expect. In fact, a text based login prompt is likely just as confusing to them as a login prompt that is polluted with boot messages as well.
These issues went away for me when I started using a SSD, so it is indeed an issue with parallel starting of services. The thing is, we all enjoy the benefits of systemd's parallel startup, it provides a much faster boot. So most of us remove the scrolling messages because it is typically scrolling too fast to make sense of anyway. But for those of you who still want those messages, you can't have the expectation that it is going to tell you about all your messages and not mess up your login prompt, knowing that parallel forces are afoot. If it were to simply throw out the last boot messages in favor or having a clean login prompt, I think then you would likely have people thinking that some of their services weren't starting or, worse, people who knew what was happening but now complained of inconsistent boot message output.
What I am trying to say is that systemd is actually doing exactly what you are asking of it. If you don't use the 'quiet' boot parameter, it is going to tell you about the crap that is is doing. If you don't intentionally use ordering or some other functionality to make sure that getty@tty1 is started after everything else, it is going to do what the system is asking of it.
Well i don't use an SSD and boot has been somewhat the same for my stripped (of starting daemons/systemd services), around 6-9 or something seconds to getty both post and pre systemd.
But i do get what you are saying, it cannot either come up with a way for starting stuff in random -first-load-first-appear-style, and still predict when getty is ready all the time.
Though i do not need parallel/un-serial starting since i do not want to use that many auto-stuff to make it worthwile - that is the way it is and i'll accept that as long as it works.
In all honestly, seeing those "Blabla started" is a sort of security-blanket, one that might not be needed 99% of the time, but i am just just to seeing it and feeling somewhat at ease or ready if there is any little whatever-majjingie that i need to look into as soon as i've logged in. That is primarily also the reason i don't boot into X per default, just in case i might need to do something in particular before the system brings up anything X-based.
A habit or a careful way, i do not know at this point
Last edited by PReP (2013-05-26 21:29:03)
#1 Main: Intel Core i5 2500k (Sandy) @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
#2 Server: Intel C2D E8400 @ 3.6 Ghz, 3 GB DDR2-RAM @ 802mhz, XFX GF GTX260 XT -ArchLinux 64-bit.
<- Server Homepage: http://prep.mine.nu ->
gilmoreja wrote:WonderWoofy wrote:
Better yet, do this:
That way you get the updates. I chose to use the .include function rather than the foo.service.d type because I am not sure how well the latter works on "@" services.
Now I am going to be really late for work!
I'm not sure if I understand the implementation properly.. Do you have all of that in a /etc/systemd/system/getty@.service file?
Yes, you include the original file and add some extra options to it. With recent systemd versions you can add multiple of these 'extensions' in the form of .conf files in a directory named after the service as in the wiki page I linked to (so .include line is no longer needed). Works fine for getty@.service, but I haven't tried it with template instances yet (as in firstname.lastname@example.org).
Thanks for the advice. This works perfectly with template instances.
I created /email@example.com, and in there put decontaminate-loginprompt.conf which simply contains the two lines
[Service] ExecStartPre=-/bin/kill -55 1
and it works like a charm.
Time you enjoy wasting isn't wasted time.
What worked for me was the second answer from this page.
I had the same problem. The problem is that netcfg takes ages (at least in my case), and that getty does not wait for netcfg (or more generally, network.target) to finish. Hence, the solution is to make getty wait.
For this, the easiest approach is to make additional configurations to the getty@.service unit file. Fortunately systemd allows us to do this without directly overwriting any files. Just create the folder /etc/systemd/system/getty@.service.d/ and add the file custom.conf inside it (actually, any filename will do, as long as it ends in .conf).
Within custom.conf you have to write:
And that should do the trick.
I don't know if this is a better strategy than that discussed above.
I also like to read my boot messages. Now I can have it all, just the way I want!