-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
Comments
Similarly, we had to do
|
I'm guessing that the |
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. |
this is still really important |
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
I marked this as stale due to inactivity. → More info |
Still relevant. |
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 |
As described in issue #81138, the Install section of upstream units is currently ignored, so we make it part of the sysinit.target manually.
Can't we just run |
@ElvishJerricco can you elaborate on the |
@aanderse When building the |
Describe the bug
I've noticed on several occasions, and again with a PR #81087 which has a unit
The
wantedBy
didn't do anything when it was included withsystemd.packages
.We had to add it manually like:
Looking at nixpkgs, it seems like others have noticed this.
The text was updated successfully, but these errors were encountered: