Bug 86415 - RFE: better warnings about where units that are missing are pulled in from, when they fail to load
Summary: RFE: better warnings about where units that are missing are pulled in from, w...
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-17 22:15 UTC by James
Modified: 2015-02-03 17:49 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description James 2014-11-17 22:15:50 UTC 
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".  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.
systemd[1]: Cannot add dependency job for unit cups.path, ignoring: Unit cups.path failed to load: No such file or directory.
systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Invalid argument
systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Invalid argument
systemd[1]: Cannot add dependency job for unit cups.service, ignoring: Invalid argument
systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.

The problem is this:  What program or configuration file caused the references to "cups.socket", "cups.path", and "cups.service"?  The systemd journal does not say, and there is no such reference in any unit file in /usr/lib/systemd/ or in /etc/systemd/.

In fact, the warning is practically useless, simply because it does not disclose the source or cause of the warning.  Neither supernatural divination nor grep has been effective in finding the source of these references thus far.

Unless these messages are meant to say that "systemd" is the source of the explicit reference to "cups.socket"?  But there is no string "cups" in "/usr/lib/systemd/systemd".

Please include the _source_ of systemd warnings in the systemd warning messages.


Thanks
James
Comment 1 James 2014-11-17 22:41:01 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?
Comment 2 James 2014-11-18 02:54:31 UTC 
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.
Comment 3 Zbigniew Jedrzejewski-Szmek 2014-12-01 01:44:55 UTC 
(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.
Comment 4 Zbigniew Jedrzejewski-Szmek 2014-12-17 01:53:31 UTC 
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.