systemd[1]: Cannot add dependency job for unit gssproxy.service

[Laurent Bonnaud]

The following error message appears in dmesg output:

[ 7.591868] systemd[1]: Cannot add dependency job for unit gssproxy.service, ignoring: Unit gssproxy.service failed to load: No such file or directory.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: nfs-common 1:1.2.8-9ubuntu8
Uname: Linux 4.0.0-040000-lowlatency x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Apr 21 22:26:49 2015
SourcePackage: nfs-utils
UpgradeStatus: Upgraded to vivid on 2015-04-20 (0 days ago)
upstart.statd-mounting.override: manual
upstart.statd.override: manual

[Laurent Bonnaud (laurent-bonnaud)]

Note that this bug has been fixed in Arch Linux:

  https://bugs.archlinux.org/task/42635

(launchpad did not recognize this URL as a foreign bug tracker)

[Steve Langasek (vorlon)]

Hi Laurent,

It's valid for systemd units to declare ordering requirements with respect to other optional units which may not be installed on the system at the time. This appears to be one of these cases. Do you see any indication that the system is behaving incorrectly, aside from this message?

[Laurent Bonnaud (laurent-bonnaud)]

> Do you see any indication that the system is behaving incorrectly, aside from this message?

I cannot tell because GSS is used for NFS+Kerberos and I do not use Kerberos on this server.

Having an error message that is not really an error is confusing, especially for an admin who tried to debug a system.
So, how about implementing the fix from Arch Linux ?

[Steve Langasek (vorlon)]

Arch solved this problem by packaging gssproxy and making nfs-utils depend on it. That's not a correct fix for a message about an *optional* service that is absent from the system

> Having an error message that is not really an error is confusing,

Not everything in the logs is an error message. I think it's clear from context that this is a warning, not an error.

[Laurent Bonnaud (laurent-bonnaud)]

> Arch solved this problem by packaging gssproxy and making nfs-utils depend on it. That's not a correct fix for a message about an *optional* service that is absent from the system.

Agreed.

However, having gssproxy in Debian/Ubuntu would a good thing, see:

  https://fedoraproject.org/wiki/Features/gss-proxy

I will file a RTP...

> Not everything in the logs is an error message. I think it's clear from context that this is a warning, not an error.

Perhaps systemd needs to make a clearer distinction between info, warning, notice, error, ...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[jdfalk (johnathan-falk)]

>> Having an error message that is not really an error is confusing,

> Not everything in the logs is an error message. I think it's clear from context that this is a warning, not an error.

Also, a warning is still warning you something is possibly wrong and to fix it. If a user is reporting that something is presenting an warning / error, it's bad policy to blame the user for not understanding this clearly enough, they are trying to help fix this and make open source better, you should welcome all feedback and say "Thank you! We will improve our messaging, and attempt to fix the issue at hand."

English is not everyone's first language, and something printed in bold in a log stands out especially when attempting to troubleshoot an issue.

[Bryan Quigley (bryanquigley)]

@laurent-bonnaud
Did you file an RTP? I couldn't find one...

I'm coming at this from https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1452667

[Launchpad Janitor (janitor)]

This bug was fixed in the package nfs-utils - 1:1.2.8-9ubuntu12

---------------
nfs-utils (1:1.2.8-9ubuntu12) xenial; urgency=medium

  * Drop gssproxy as it's not in Ubuntu (LP: #1446851)
  * Fix no nfs doesn't show failed units on client (LP: #1452667)

 -- Bryan Quigley <email address hidden> Wed, 02 Mar 2016 15:01:29 -0500