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

wantedBy not working when used from upstream systemd units #81138

Open
worldofpeace opened this issue Feb 26, 2020 · 10 comments
Open

wantedBy not working when used from upstream systemd units #81138

worldofpeace opened this issue Feb 26, 2020 · 10 comments
Labels

Comments

@worldofpeace
Copy link
Contributor

worldofpeace commented Feb 26, 2020

Describe the bug
I've noticed on several occasions, and again with a PR #81087 which has a unit

# tlp - systemd startup/shutdown service
#
# Copyright (c) 2020 Thomas Koch <linrunner at gmx.net> and others.
# This software is licensed under the GPL v2 or later.

[Unit]
Description=TLP system startup/shutdown
After=multi-user.target NetworkManager.service
Before=shutdown.target
Documentation=https://linrunner.de/tlp

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/nix/store/42m41jbsvbc7qh25k42cdc5jf2yjsf87-tlp-1.3.1/sbin/tlp init start
ExecStop=/nix/store/42m41jbsvbc7qh25k42cdc5jf2yjsf87-tlp-1.3.1/sbin/tlp init stop

[Install]
WantedBy=multi-user.target

The wantedBy didn't do anything when it was included with systemd.packages.

We had to add it manually like:

systemd.services.tlp.wantedBy =  [ "multi-user.target" ];

Looking at nixpkgs, it seems like others have noticed this.

@worldofpeace worldofpeace added the 0.kind: bug Something is broken label Feb 26, 2020
@worldofpeace
Copy link
Contributor Author

Similarly, we had to do wants manually in gnome-settings-daemon

systemd.user.targets."gnome-session-initialized".wants = [
. But everything has the links in the package.

@lheckemann
Copy link
Member

lheckemann commented Feb 28, 2020

I'm guessing that the [Install] section, which is put into effect by systemctl enable which in turn creates symlinks in /etc/systemd/system/multi-user.target.wants (for instance), is not currently respected by systemd.packages. EDIT: i.e. we need to use or emulate the behaviour of systemctl enable

@stale
Copy link

stale bot commented Aug 26, 2020

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Aug 26, 2020
@worldofpeace
Copy link
Contributor Author

this is still really important

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Aug 27, 2020
rnhmjoj added a commit to rnhmjoj/nixpkgs that referenced this issue Feb 21, 2021
It's a dull and boring day, it's cold outside and I'm stuck at home: let
me tell you the story of systemd-vconsole-setup.

In the beginnings of NixOS[1], systemd-vconsole-setup was a powerful
sysinit.target unit, installed and running at boot to set up fonts
keyboard layouts and even colors of the virtual consoles. If needed, the
service would also be restarted after a configuration change, consoles
were happy and everything was good, well, almost.

Since the service had no way to specify the dependency "ttys are ready",
modesetting could sometimes happen *after* systemd-vconsole-setup had
started, leaving the console in a broken state. So abbradar worked
around that by putting a systemd-udev-settle `After=`.

In the meanwhile, probably realizing their mistake, systemd added a
shiny udev rule to start the systemd-udev-settle at the right time[2].
However, the rule bypassed systemd by directly running the binary
`systemd-udev-settle`, and the service - though still installed - fell
into disuse.

Two years would pass before a good samaritan, seeing the poor jobless
systemd-udev-settle service, decided to give it the coup de grâs[3] by
unlisting it from the installed units.
This, combined with another bug, caused quite a commotion[4] in NixOS;
to see why remember the fact that `WantedBy=` in upstream units doesn't
work[5], so it had to be added manually in cc54211, but while systemd
removed it, the NixOS unit continued to install and restart the service,
making a lot of fuss when switching configuration.

After at least thee different tentative fixes, deedrah realised[6] what
the root cause was and fpletz put the final nail[7] in the coffin of
systemd-udev-settle. The service would never see the light of a boot
again, NixOS would not restart it all the time but thanks to udev
consoles would still get their pretty fonts and playful colors.

The En..

..no, wait! You should ask what came of systemd-udev-settle, first.
And why is the service even around if udev is doing all the work?

Udev-settle, like the deceitful snake that he is, laid hidden for years.
He looks innocuous doesn't it? A little hack. Only until it leaves his
den and a poor user[8] drops dead. Obviously, it serves no purpose, as
the service is not part of the boot process anymore, so let's remove it
for good!

About the service, it may not be useful at boot, but it can be started
to pick up changes in vconsole.conf and set the consoles accordingly.
But wait, this doesn't work anymore: the service is never started at
boot (remember f76d2aa), so switch-to-configuration.pl will not restart
it. Fortunately it can be repaired: here I install a new unit which
does *nothing* on start, but restarts the real service when reloaded.
This perfectly reproduces the original behavior, hopefully without the
original bugs too.

The End?

[1]: NixOS@cc54211
[2]: systemd/systemd@f6ba867#diff-84849fddcef81458f69725dc18c6614aade5c4f41a032b6908ebcf1ee6740636
[3]: systemd/systemd@8125e8d
[4]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470
[5]: NixOS#81138
[6]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470#issuecomment-330930456
[7]: NixOS@f76d2aa
[8]: NixOS#107341
@stale
Copy link

stale bot commented Feb 23, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Feb 23, 2021
@aanderse
Copy link
Member

Still relevant.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Feb 24, 2021
@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/disable-a-systemd-service-while-having-it-in-nixoss-conf/12732/3

flokli pushed a commit that referenced this issue May 16, 2021
As described in issue #81138, the Install section of upstream units is
currently ignored, so we make it part of the sysinit.target manually.
@aanderse aanderse mentioned this issue May 27, 2021
10 tasks
@aanderse aanderse mentioned this issue Nov 4, 2021
12 tasks
LunNova added a commit to LunNova/nixos-configs that referenced this issue Jan 1, 2022
@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 19, 2022
@ElvishJerricco
Copy link
Contributor

Can't we just run systemctl enable --root=where/ever * or something?

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Dec 17, 2022
@aanderse
Copy link
Member

@ElvishJerricco can you elaborate on the --root=where/ever part?

@ElvishJerricco
Copy link
Contributor

@aanderse When building the generateUnits derivation, we could do something along the lines of for x in ${units}; do systemctl enable --root=$out $x; done. The --root arg makes it operate on a different root tree and not on any running daemon, so all it will do is create necessary symlinks and implement the [Install] section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants