| Summary: | RFE: better warnings about where units that are missing are pulled in from, when they fail to load | ||
|---|---|---|---|
| Product: | systemd | Reporter: | James <james> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | NEW --- | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
James
2014-11-17 22:15:50 UTC
To be more clear, with reference to the above cups warnings: _What_ file or program asked for unit "cups.socket", which failed to load because there is No such file or directory? _What_ file or program specified the argument "cups.service", such that the argument was invalid? Ok, I found the source of these, with a little help from someone having a better grasp of systemd. Silly me - I was looking for a reference from within the unit files, rather than a reference from the systemd/system/ directories. The messages are generated from left-over links in /etc/systemd/system/{multi-user.target.wants/cups.path, printer.target.wants/cups.service, sockets.target.wants/cups.socket} to non-existent unit files in /usr/lib/systemd/system/.
So, is there some way, in this case, to have an explicit reference back to the broken link? Something like:
From /etc/systemd/system/sockets.target.wants/cups.socket - Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
and
From /etc/systemd/system/printer.target.wants/cups.service - Cannot add dependency job for unit cups.service, ignoring: Invalid argument
Or - perhaps systemd could be a little smarter about not following broken links. The log message could then say something more direct, like:
/etc/systemd/system/printer.target.wants/cups.service: No such file or directory.
(In reply to James from comment #0) > Version: systemd 217-6 on Arch Linux > > The new version 2.0.0 of cups has changed the unit file names from the form > "cups.service" to "org.cups.cupsd.service". Please, *noooooo*. > While the name change seems > gratuitous, there is still "something" which attempts to access the old unit > file names. Upon reboot, with kernel loglevel=6, when cupsd starts, and > various other times, "journalctl -b" shows warnings like: > > systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit > cups.socket failed to load: No such file or directory. I think the names of units are included in one of the extra fields visible in 'journalctl -o verbose' output. But you're right, we should include the name of the other unit in the output too. We could do that by storing the location for each symlink (something like FragmentPath that we have for unit files). OTOH, this would be a fairly heavy price to pay for a somewhat esotiric use case. Apart from missing dependencies, and dependency cycles, I don't think we could make use of it anywhere systemd. We could use it in systemctl cat to also show the configuration done through symlinks. That last part would definitely be useful. So it's certainly worth considering. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.