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

Failing systemd Services in CentOS 8-Stream #141

Closed
adamgranthendry opened this issue Apr 15, 2021 · 13 comments
Closed

Failing systemd Services in CentOS 8-Stream #141

adamgranthendry opened this issue Apr 15, 2021 · 13 comments
Assignees
Labels
bug Something isn't working

Comments

@adamgranthendry
Copy link

Windows version (build number):
1909, Build 18363.1440

Linux distribution:
CentOS 8-Stream downloaded from mishamosher and installed via .exe in .zip asset (version 20210210)

Genie version:
1.36

Describe the bug
Within an open zshell in WSL2 with Windows Terminal (version 1.6.10571.0), I execute

genie -i > /dev/null &
genie -s

3 services are failing upon initialization of genie:

  • auditd.service
  • systemd-modules-load.service
  • systemd-remount-fs.service

The failure was first noticed by running

sudo systemctl status

and noticing the state was degraded. The specific failing units were determined by running

sudo systemctl list-units --failed

The specific errors for each service are found by running

systemctl status <name.service>

where <name.service> is the name of the service.

auditd.service

image

systemd-modules-load.service

image

systemd-remount-fs.service

image

Questions

  1. Can these services safely be ignored?

If so, I can run

systemctl stop <name.service>
systemctl disable <name.service>

for each

  1. Services usually fail because of a missing dependency (e.g. a file or mount point), missing configuration, or incorrect permissions. If I should not ignore that these services failed, what steps can I perform to fix these services?

Any help would be greatly appreciated!

@adamgranthendry adamgranthendry added the bug Something isn't working label Apr 15, 2021
@cerebrate
Copy link
Member

Just put details on known-problematic units here:

https://github.com/arkane-systems/genie/wiki/Systemd-units-known-to-be-problematic-under-WSL

Short version: you'll probably want to disable those three. (But full details are there.)

Also:

genie -i > /dev/null & genie -s

You don't need to do this. genie -s, -l, and -c all initialize the bottle if it isn't already preinitialized. -i exists so you can preinit it on startup and thus speed up the others/have services already running in the background. If you aren't doing either of those, you don't need it.

@PavelSosin-320
Copy link

@adamgranthendry

  1. You can list all failing units using sustemctl --failed and find detail documentation about every service in the Linux documentation including outcome of its disabling.
  2. Microsoft WSL Kernel provides limited capabilities in 2 areas: networking and security: Selinux and Security audit are neglected.
  3. Some units can fail to start because "Energy saving" mode makes full system startup too slow and timeout comes 1st.A service has such dependency it can't start unless MS will include it into its Kernel.
    Anyway, some failed or disabled units don't make the distro unusable. The proper configuration of Network services like systemd-resolved and Network Manager produces much better results than dumb WSL network configuration unsuitable for the modern network layouts managed by Broadband Wireless Combo modem-routers or meshes.

@adamgranthendry
Copy link
Author

adamgranthendry commented Apr 16, 2021

@cerebrate Thank you so much! That is great news! Yes, I will safely disable those then.

FYI, @tdcosta100 uses

genie -i > /dev/null &
genie -s

in his gist for installing GUIs in WSL2.

  1. Should I give him a heads up that this command should be replaced with genie -s?
  2. Once I disable the failing units, will they remain disabled so that I can use the auto-bootup sequence in your wiki (that I put into ~/.zprofile) without getting the Waiting for systemd...!!!! "error".

@PavelSosin-320 Thank you very much! That is very useful information. It appears that from your and @cerebrate 's information that I can safely disable these services in WSL 2, which is great! Your help is much appreciated!

@cerebrate
Copy link
Member

  1. No worries, I'll drop him a line myself.
  2. If you disable them, they'll stay disabled, yeah.

You'll always get "Waiting for systemd...!!!" to a degree, because that's literally what it's doing - waiting for everything to be set up before you try to do anything in the bottle, in the same way that native Linux won't give you a login prompt until the system's booted up enough to support a user session. But it will be quicker when it's not waiting on units that can't start properly.

@PavelSosin-320
Copy link

@adamgranthendry You can also create additional Linux users and user Windows Terminal sessions to create new rootles user sessions. Just create a new Linux user and add a new entry in the WT setting:
{
"commandline": "wsl -d fedoraremix -u root genie -l",
"guid": "{9bf73832-84d5-44d5-87d9-3e60f3cd930e}",
"hidden": false,
"name": "FedoraPavel"
}
with a distro name, unique guide, and display name by your choice. Login service, the Session manager will work like on the regular hardware or VM.

@adamgranthendry
Copy link
Author

@cerebrate In CentOS 8, as root, I cannot stop auditd. Normally, I would switch to root and use

sudo service auditd stop

but this is failing for some reason:

Stopping logging:    [FAILED]

How can I stop auditd?

@adamgranthendry
Copy link
Author

@cerebrate My bad once again. I should have just issued (as root):

sudo systemctl disable auditd.service

@PavelSosin-320
Copy link

@adamgranthendry Don't stop audit, simply disable. The corresponding module is missed in the hard-built MS WSL Kernel and there is no way to load it dynamically. Such a security issue is OK from the Microsoft point of view. Even passing audit=1 as a Kernel Command string parameter does nothing.

@adamgranthendry
Copy link
Author

adamgranthendry commented Apr 17, 2021

@PavelSosin-320 Thank you. FYI,

sudo systemctl disable systemd-modules-load.service
sudo systemctl disable systemd-remount-fs.service

doesn't work, but

sudo systemctl mask systemd-modules-load.service
sudo systemctl mask systemd-remount-fs.service

does. Not sure why. Now when I restart WSL (wsl --shutdown from PowerShell) and open CentOS 8, I get a "green light" for sudo systemctl status:

image

@adamgranthendry
Copy link
Author

adamgranthendry commented Apr 17, 2021

@PavelSosin-320 and @cerebrate If I put just

# Start systemd genie
if [[ ! -v INSIDE_GENIE ]]; then
  exec /usr/bin/genie -s
fi

in my .zprofile, Cent OS 8 crashes on startup. Any idea why?

Other than that, I edited /etc/genie.ini to:

[genie]
secure-path=/lib/systemd:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sb$unshare=/bin/unshare
unshare=/bin/unshare
update-hostname=true
clone-path=true
clone-env=WSL_DISTRO_NAME,WSL_INTEROP,WSLENV
systemd-timeout=3

i.e. set unshare to /bin/unshare (which unshare points here), clone-path to true, systemd-timeout to 3 seconds.

and manually created ~/.zprofile and entered the settings there.

And also, even putting the script at the end of my existing /etc/zprofile causes it crash...Any ideas?

@adamgranthendry
Copy link
Author

@cerebrate and @PavelSosin-320 There's only one other thing I see that I don't understand. When I run sudo genie -s, it finishes and outputs

/etc/profile.d/which2.sh:export:18: invalid option(s)

What is that and how do I fix it?

@PavelSosin-320
Copy link

@adamgranthendry I use more straightforward way to start my distro with genie: Windows shortcut for the command line
wsl -d Fedora-in-my-case -u root genie -s. It works also for the blank root profile. When I log in as another user I use genie -l and give logind to do its job: create a user session, cgroup slice, configure the profile, etc. In such distros as CentOS, Ubuntu, Fedora the difference between root and rootless user sessions are much deeper than plain file access. The process tree for the root and rootless users is different. The service configurations for the root and rootless users are separated too because services can be root or rootless. You can start systemd but without systemd's login and session nothing will work.

@cerebrate
Copy link
Member

cerebrate commented Apr 18, 2021

@adamgranthendry /etc/profile.d is where site-specific shell profiles go. If you didn't install that file there, I presume it came with CentOS, and you're probably best off asking them about it.

systemd-timeout=3

Shortening the timeout this much effectively bypasses the mechanism that keeps you from trying to invoke systemd services before systemd has initialized. (The timeout should be long enough that under any possible non-failure scenario systemd should have reached the running state before the timeout expires.) This is not a supportable or supported configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants