The problem persists with systemd 189

I have the same situation.

I updated the system. During update some packages were replaced with 'systemd'. Then suggestion appeared - to append 'init=/bin/systemd' to kernel command line options in a bootloader. I did it in my syslinux bootloader.

After reboot a lot of messages appeared.
[ OK ] ..........
[ OK ] ..........
[ OK ] ..........

Here login prompt appears

[ OK ] ..........
[ OK ] ..........
[ OK ] ..........

I have the same problem. Arch Linux, systemd 194.

http://unix.stackexchange.com/questions/51805/systemd-messages-after-starting-login/

Confirmed on ArchLinux x64 with systemd 195.

One more confirmation Arch Linux x64 with systemd 195.

One thing to note is that this only happens with a slow disk (i.e 7.2K HDD) and never with an SSD (YMMV, though).

This leads me to believe that the SSD is simply masking the real problem; i.e the login prompt being displayed before all services are fully initialized.

just wanted to subscribe and confirm the bug.

Arch Linix x86_64, systemd 195

I can also confirm this bug

systemd 196
64bit archlinux

Confirming this bug.

systemd 196 on Arch x64

I confirm the bug on systemd 196 and subscribe.
Archlinux 64bits.

(In reply to comment #6)
> just wanted to subscribe and confirm the bug.
> 
> Arch Linix x86_64, systemd 195

I was able to solve my issue by changing the Type of the services (dhcpcd, httpd, mysqld) that was generating output after login prompt to "idle". (It was forking before)

This might not be a suitable final solution, but enough to get rid of the annoyance while permanent fix comes in.

(In reply to comment #10)
> (In reply to comment #6)
> 
> I was able to solve my issue by changing the Type of the services (dhcpcd,
> httpd, mysqld) that was generating output after login prompt to "idle". (It
> was forking before)

Correction:
Had to revert httpd back to forking, still the problem went away by changing the other two.

This is still reproducible with systemd 197. Half a year and no reaction on this. Is this not a bug?

reproduces on systemd-201-1

(In reply to comment #13)
> reproduces on systemd-201-1

For some reason this appears to happen on Arch. Can you provide the output of 'journalctl -b' after booting with systemd.log_level=debug on the commandline?

Thanks.

Created attachment 81168 [details]
Output of 'journalctl -b'

This still reproduces on 204. The output of 'journalctl -b' with systemd.log_level=debug is attached. I hope this helps. Thank you.

OK, so we actually wait for other jobs to finish before Type=idle jobs are allowed to commence, but we *report* the other jobs afterwards.

[  OK  ] Started Login Service.
------------------ here actually systemd waits for slow.service -----

Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.2-200.fc18.x86_64 on an x86_64 (console)

fedora login: [  OK  ] Started slow.service.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.

Hm, actually my previous comment was totally wrong. We simply delay the idle jobs for a maximum of IDLE_TIMEOUT_USEC (which is defined to 5 s). It is relatively easy to have services which take more than 5 s to start, and then gettys will be launched while other things are still being started.

We could bump those 5 s to something bigger, but there are huge downsides - if something goes wrong, logging in will be impossible for longer, potentially indefinitely. So setting the timeout to something huge or infinity seems risky.

Type=idle is a hack, and it shows here. It's seems unlikely that we can find an IDLE_TIMEOUT_USEC value which will satisfy everybody. Actually 5 s seems to be a reasonable value.

A more complicated option would be to add an additional target, let's say multi-user-post.target, which would be After=multi-user.target, Requires=multi-user.target, and make getty services be part of it. It would be a solution with the similar downsides as simply increasing the IDLE_TIMEOUT_VALUE, unlikely to be worth it.

Dunno, we could also export IDLE_TIMEOUT_USEC as a config option. But it is a very low-level thingy, and not something that should be a part of the external interface. Maybe IDLE_TIMEOUT_USEC should instead be scaled by the number of jobs and processor speed or having a SSD/non-SSD disk. Again, probably not worth the hassle for a cosmetic issue.

I'm resetting this to NEW, maybe somebody can come up with a solution.

For the problem you are discussing, it basically seems like systemd and the login prompt are outputting to the same console at the same time. getty is started and outputs the login prompt but systemd is still running and sends its own output.

Since systemd is PID 1 and monitors the whole system, then it should check whether something has grabbed the terminal before it outputs something to it... There's even TTYPath and the like in service files...

Created attachment 82068 [details] [review]
Proposed patch

Please check, if the proposed patch fixes your issue.

Created attachment 82069 [details] [review]
Proposed revised patch

> Created attachment 82069 [details] [review] [review]
With this patch, all output is cut off immediately after getty start jobs are queued, and not only after the 5s timeout is done. This does the job, but totally destroys the whole idea of Type=idle.

Fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=31a7eb8.

Type=idle jobs will wait for 5 s for the bootup to finish. If the bootup doesn't finish in time, the later part of output simply isn't shown.