Bug 1291062
Summary: | custom service files half-disappear from systemd until rename: "No such file or directory", cannot start service | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Trevor Cordes <trevor> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | johannbg, jsynacek, lnykryn, msekleta, s, systemd-maint, trevor, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-02-02 07:22:59 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Trevor Cordes
2015-12-13 10:45:56 UTC
I don't know about the disappearing stuff, but... You're not supposed to put services directly to /etc/systemd/system/multi-user.target.wants/. Put your service file to /etc/systemd/system/ and run "systemdctl enable <service>". Since your service file already contains the correct [Install] section, your service will be correctly enabled. Does this help? Haven't had this problem again, yet, since a couple of days after the report. Perhaps some update somewhere solved it. However, I'm not convinced so I'm waiting to see if it comes up again. If it doesn't hit for a few months I guess it's fixed. I will try relocating the service files as you suggest next time there is a problem to see if that helps. However, whether a symlink or a real file systemd shouldn't care, but who knows what it's doing under the hood I guess. Just hit again on another box I run. This time it was RIGHT after a dnf update that updated systemd: was: systemd-219-26.fc22.i686 now: systemd-219-27.fc22.i686 #ll /etc/systemd/system/multi-user.target.wants/tec-restarter.service -rw-r--r-- 1 root root 278 Apr 3 2015 /etc/systemd/system/multi-user.target.wants/tec-restarter.service #systemctl restart tec-restarter.service Failed to restart tec-restarter.service: Unit tec-restarter.service failed to load: No such file or directory. Exit 6 #systemctl daemon-reload #systemctl restart tec-restarter.service Failed to restart tec-restarter.service: Unit tec-restarter.service failed to load: No such file or directory. Exit 6 #systemctl status tec-restarter.service * tec-restarter.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) since Tue 2016-02-02 00:50:28 CST; 4min 39s ago Main PID: 14048 (code=killed, signal=TERM) Exit 3 Looks like your idea fixes the problem!: #mv /etc/systemd/system/multi-user.target.wants/tec-restarter.service /etc/systemd/system #systemctl enable tec-restarter.service Created symlink from /etc/systemd/system/multi-user.target.wants/tec-restarter.service to /etc/systemd/system/tec-restarter.service. #ll /etc/systemd/system/multi-user.target.wants/tec-restarter.service lrwxrwxrwx 1 root root 41 Feb 2 00:55 /etc/systemd/system/multi-user.target.wants/tec-restarter.service -> /etc/systemd/system/tec-restarter.service #systemctl restart tec-restarter.service #systemctl status tec-restarter.service * tec-restarter.service - tec restarter Loaded: loaded (/etc/systemd/system/tec-restarter.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2016-02-02 00:56:18 CST; 1min 54s ago So I will move on all my boxes all my custom service files an enable the symlinks instead. If no one cares that putting those files in multi-user.target.wants directly vs using the symlinks results in NON-DETERMINSTIC behaviour then we'll close this bug as NOTABUG. I say non-deterministic because I have dozens of boxes each with about a dozen custom service files and a) worked great for, how long has systemd been in fedora, 4 years?; and b) this bug rarely pops up even with the myriad replications of the prerequisites; and c) renaming the service file but staying in multi-user.target.wants usually makes the symptom disappear; and d) the error message systemd is giving me is Really Bad (no such file? huh?). I won't be the first or last person to put service files where they seem to go (remember, I did this before all the nice RH docs about this were in place)! P.S. /etc/systemd/system is a real ugly place to put them... there should be a nice separate directory, rather than cluttering up the has-lots-of-subdirs-and-really-shouldn't-contain-files /etc/systemd/system. Maybe /etc/systemd/system/local or something. It's like systemd designers didn't think anyone would ever make their own service files, even though there's a ton of devs who used to have extensive /etc/inittab file contents. Thanks! |