Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(network-manager): disable tty output if the console is not usable #1611

Merged
merged 2 commits into from
Oct 21, 2021

Conversation

bengal
Copy link
Contributor

@bengal bengal commented Sep 24, 2021

The network-manager module also writes logs to the console, so that it's easier to debug network-related boot issues. If systemd can't open the console, the service fails and network doesn't get configured.

Add a check to disable tty output when the console is not present or not usable.

coreos/fedora-coreos-tracker#943

Checklist

  • I have tested it locally

@github-actions github-actions bot added modules Issue tracker for all modules network-manager Issues related to the network-manager module labels Sep 24, 2021
@johannbg
Copy link
Collaborator

Hmm this seems somewhat backwards.
I expect/would think that the NM module by default should not be started in debugging mode thus outputting things to the console unless either rd.debug is found on the kernel commandline and or some nm.debug kernel commandline parameter is in use so perhaps a better fix might be to include two unit files, one that starts normall and another that starts if debug options are enabled as in the "standard" one would have ConditionKernelCommandLine=!FOO.NM.DEBUG and starts NM without debug being enabled while the debug one would have ConditionKernelCommandLine=FOO.NM.DEBUG in them.

@bengal
Copy link
Contributor Author

bengal commented Sep 27, 2021

I expect/would think that the NM module by default should not be started in debugging mode thus outputting things to the console unless either rd.debug is found on the kernel commandline and or some nm.debug kernel commandline parameter is in use

Good point, there should be no output on console unless the command line contains rd.debug. I've added a commit to change that.

a better fix might be to include two unit files, one that starts normally and another that starts if debug options are enabled

I'm not sure about this; having two units means that every change must be duplicated in both files and it's easy to get them out of sync by mistake. How about changing only the needed options through a drop-in file instead?

if [ -n "$DRACUT_SYSTEMD" ]; then
# enable tty output if an usable console is found
# shellcheck disable=SC2217
if [ -w /dev/console ] && (echo < /dev/console) > /dev/null 2> /dev/null; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume echo < /dev/console is a test and will fail if the console doesn't work? It seems weird to me to send anything to stdin of echo since it doesn't do anything with it. cat does.

Also:

Suggested change
if [ -w /dev/console ] && (echo < /dev/console) > /dev/null 2> /dev/null; then
if [ -w /dev/console ] && (echo < /dev/console) &> /dev/null; then

I think this is equivalent with less characters.

Copy link
Contributor Author

@bengal bengal Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume echo < /dev/console is a test and will fail if the console doesn't work? It seems weird to me to send anything to stdin of echo since it doesn't do anything with it. cat does.

I copied this code from https://github.com/dracutdevs/dracut/blob/055/modules.d/99shutdown/shutdown.sh#L15

The idea is to try to open the console via shell redirection, but don't actually read or write anything from/to it. If /dev/console can't be opened, the command returns a non-zero value which is interpreted as false.

I think this is equivalent with less characters.

The interpreter of this script is /bin/sh, so it must be POSIX compatible.
&> is a bashism and is not POSIX.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the reply/explanation.

[Service]
StandardOutput=tty
EOF
systemctl --no-block daemon-reload
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any implications of running this daemon-reload here? If we ran this as part of a systemd generator would we need to do the daemon-reload?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not aware of any side effect of calling daemon-reload here.

A generator would be an alternative and wouldn't require a daemon-reload; I think it requires to ship new service and a script. I like how the current code is self-contained, but I have no objections in turning it into a generator if that's the general consensus.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lucab - any thoughts here on the tradeoffs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, reloading in the middle of a boot isn't the nicest, a generator would be advisable.
I don't think it directly breaks anything so not strictly a problem, but may trigger some unexpected second-order effects.
For reference, I see there are some dracut modules already shipping a generator in this repository, like modules.d/95nbd/.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree a generator would be slightly cleaner and would make a good follow-up, but if this is already tested IMO it's not worth the respin.

The module should show the output on console only when initrd debugging is
enabled.
Copy link
Contributor

@dustymabe dustymabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems fine to me

The network-manager module also writes logs to the console, so that it's easier
to debug network-related boot issues. If systemd can't open the console, the
service fails and network doesn't get configured.

Add a check to disable tty output when the console is not present or not
usable.

coreos/fedora-coreos-tracker#943
@dustymabe
Copy link
Contributor

@johannbg - can we merge this?

Copy link
Collaborator

@johannbg johannbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@johannbg johannbg enabled auto-merge (rebase) October 19, 2021 20:28
@johannbg
Copy link
Collaborator

@dustymabe I've ack this but it needs second review from @haraldh before it can be merged.

Copy link
Collaborator

@haraldh haraldh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so ugly... but if you insist...

@johannbg johannbg merged commit f6e6be2 into dracutdevs:master Oct 21, 2021
@dustymabe
Copy link
Contributor

This is so ugly

can you elaborate? obviously we're interested in an expert's opinion on best way to achieve something.

@haraldh
Copy link
Collaborator

haraldh commented Oct 22, 2021

All output of services is normally logged to the systemd journal anyway. There exist kernel command line options to display the output of the journal like systemd.journald.forward_to_console or IIRC, rd.systemd.journald.forward_to_console.

You can even get a systemd driven shell with rd.systemd.debug_shell and display the nm-initrd.service log entries.

If StandardOutput is going to the tty this information is lost for the journal. journal+console would be a better config anyway.

@dustymabe
Copy link
Contributor

Thanks for the explanation.

LaszloGombos pushed a commit to LaszloGombos/dracut that referenced this pull request Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
modules Issue tracker for all modules network-manager Issues related to the network-manager module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants