[systemd-devel] [PATCH 0/3] Fix issues re: visibility of status messages

[Olivier Brunel]

On 11/14/13 05:40, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Sep 20, 2013 at 10:18:27PM +0200, Olivier Brunel wrote:
>> Hi,
>>
>> I'm running Arch Linux, have been using systemd-204, and recently tried the new
>> 207 release, and I have been having some issues with it. One was that status
>> messages would just stop at some point near the end of the boot process, and
>> also that I wouldn't get any during a shutdown/reboot.
>>
>> It might be useful to note that I don't start a getty on tty1, which is why I
>> expect to see all status messages until default target is reached, even after
>> the getty/login has been started (which happens on tty2).
>>
>> After looking into it, I came up with the following patches to fix the issue.
>> The reason status messages would stop was that the getty was started, and
>> systemd then stopped using the console to avoid "collisions" w/ gettys.
>>
>> However, as I said I don't have a getty started on tty1 so for me that is a bug,
>> as there's no reason not to keep printing status messages on tty1.
>>
>> The lack of messages on shutdown/reboot was also linked to this, because if
>> no_console_output was set to true during boot, it'd stay there and prevent
>> messages to show up on shutdown.
>>
>> To fix this (in the event it was set to true on boot) a patch simply resets it
>> to false on job_shutdown_magic(), but I'm not exactly sure if that's the right
>> way to do this.
> All 3 patches applied. I *think* they are all correct, but this code
> has so many corner cases that it's hard to be sure. I made some
> tweaks, please check that it still works. Sorry for the delay. In the
> future, if you don't get an answer within a week or two, please holler :)
> Patches do sometimes slip through, especially when there are a lot
> of changes like recently, and a ping to the ml will help to bring the
> thread to the bottom. 

Noted, thanks. Tried the latest git, it all works as expected.

> 
>> FYI I should add that in a similar setup as the one I described, this will not
>> be enough to keep messages on tty1, since fsck's units are now RemainAfterExit
>> (see https://bugs.freedesktop.org/show_bug.cgi?id=66784), which means they're
>> seen by systemd as "owning" the console (as far as outputing messages there is
>> concerned I mean), and it will therefore stop printing status messages.
>>
>> I'm not sure you want to "fix" this, as it might be only a cosmetic issue for a
>> small usecase hence not worth the trouble, so I've simply "undone" it using a
>> .conf file on my end, figured I should mention it though.
> Hm, we could detect this case by looking at services in the SERVICE_EXITED
> substate. It might actually be worth fixing, since almost everything now
> is RemainAfterExit=true.

Alright, I've looked into this a bit, I'll send a patch that should
handle it as well.

-j

> 
> Zbyszek
>