http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c1 boo35 boo35 <9b3e05a5@opayq.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |neilb@suse.com Flags| |needinfo?(neilb@suse.com) --- Comment #1 from boo35 boo35 <9b3e05a5@opayq.com> --- Note 2 rpc-*gssd.service files systemctl list-unit-files | grep gss auth-rpcgss-module.service static rpc-gssd.service static rpc-svcgssd.service static both provided by CLIENT 'nfs-client' package, rpm -q --whatprovides /usr/lib/systemd/system/rpc-gssd.service /usr/lib/systemd/system/rpc-svcgssd.service nfs-client-1.3.0-9.1.x86_64 nfs-client-1.3.0-9.1.x86_64 but both (1) providing SERVER security svcs, and (2) looking very similar cat rpc-gssd.service [Unit] Description=RPC security service for NFS client and server DefaultDependencies=no Conflicts=umount.target Requires=var-lib-nfs-rpc_pipefs.mount After=var-lib-nfs-rpc_pipefs.mount ConditionPathExists=/etc/krb5.keytab PartOf=nfs-utils.service Wants=nfs-config.service After=nfs-config.service [Service] EnvironmentFile=-/run/sysconfig/nfs-utils Type=forking ExecStart=/usr/sbin/rpc.gssd $GSSDARGS cat rpc-svcgssd.service [Unit] Description=RPC security service for NFS server DefaultDependencies=no Requires=var-lib-nfs-rpc_pipefs.mount After=var-lib-nfs-rpc_pipefs.mount local-fs.target PartOf=nfs-server.service PartOf=nfs-utils.service After=gssproxy.service ConditionPathExists=|!/run/gssproxy.pid ConditionPathExists=|!/proc/net/rpc/use-gss-proxy ConditionPathExists=/etc/krb5.keytab Wants=nfs-config.service After=nfs-config.service [Service] EnvironmentFile=-/run/sysconfig/nfs-utils Type=forking ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS Why are there 2 similar services here? Wondering if that's causal at boot. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c2 Dieter Jurzitza changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dieter.jurzitza@t-online.de --- Comment #2 from Dieter Jurzitza --- An IMHO related issue: nfs-utils require gssproxy in their systemd - files, however, gssproxy is not offered by any package. This is causing continuous error messages from systemd, filling logs. The same holds true for nfs-server.service nfs-client.target nfs-server.service rpc-svcgssd.service all refer to gssproxy.service -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c4 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(neilb@suse.com) | --- Comment #4 from Neil Brown --- 1/ rpc-svcgssd.service shouldn't try do start unless you have the file /etc/krb5.keytab. This is due to the line "ConditionPathExists=/etc/krb5.keytab" in /usr/lib/systemd/system/rpc-svcgssd.service Do you have the file? Do you want to have it? Can you remove it? What then happens? 2/ Yes, we do need both rpc-gssd.service and rpc-svcgssd.service One works with the client side of the connection. one with the server side. As NFSv4.0 uses callbacks from the server to the client, the server sometimes acts as a client and the client acts as a server. So to support NFSv4.0 we need to run both services on both the server and the client. 3/ While we probably should support gssproxy at some stage (thanks for the spec file) NFS should work properly with out it - using {svc,}gssd instead. What error messages are filling up the log files? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c6 Dieter Jurzitza changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(neilb@suse.com) | --- Comment #6 from Dieter Jurzitza --- In reply to #4: Dec 12 00:15:01 djunix systemd[1]: Cannot add dependency job for unit gssproxy.service, ignoring: Unit gssproxy.service failed to load: No such file or directory. By the way, nfs is working fine here, but messages that are repeated all over and over again, filling the logs are not the way things ought to be (IMHO). Using the specfile I provided I have built and installed gssproxy successfully, since then the missing dependency messages disappeared, however, gssproxy was started as a deamon, what does not seem to harm anyway. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c8 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |9b3e05a5@opayq.com Flags| |needinfo?(9b3e05a5@opayq.co | |m) --- Comment #8 from Neil Brown ---

Why is

ConditionPathExists=/etc/krb5.keytab

uses in lieu of that config option to make that decision?

Partly because that it what upstream nfs-utils does, and there is a lot of value in using the same systemd unit files as upstream (but then, I put that stuff upstream, that that isn't really an excuse). Partly because systemd doesn't make it at all easy to selectively enable/disable services using a env variables in a config file. Is this causing any actual problems apart from the unsightly error message? If not it might be simplest just to find a way to hide the error message. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c10 boo35 boo35 <9b3e05a5@opayq.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(9b3e05a5@opayq.co | |m) | --- Comment #10 from boo35 boo35 <9b3e05a5@opayq.com> --- (In reply to Neil Brown from comment #8)

Is this causing any actual problems apart from the unsightly error message?

Well, maybe ... http://lists.opensuse.org/wicked-devel/2015-12/msg00000.html NFS-related dependencies are definitely at issue, between that thread and this bug, at least. Whether they're related or not, I don't yet know. I'm poking at it trying to figure out what's causal etc. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c12 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #12 from Neil Brown --- (In reply to boo35 boo35 from comment #10)

(In reply to Neil Brown from comment #8)

...

Is this causing any actual problems apart from the unsightly error message?

Well, maybe ...

http://lists.opensuse.org/wicked-devel/2015-12/msg00000.html

This looks like it might be the same as bug 947483 ... which you probably cannot see because it is against SLES12-SP1 rather than opensuse. But I believe SLE12 fixes get into Leap, so it should be fixed.... but it looks like it isn't. The fix removes references to $remote_fs from /etc/init.d/named and /etc/init.d/lwresd

NFS-related dependencies are definitely at issue, between that thread and this bug, at least.

Whether they're related or not, I don't yet know. I'm poking at it trying to figure out what's causal etc.

Yeah, it's complex. And systemd is new and different and there is a bit of a learning curve. systemd doesn't make it at all easy for service execution to be controlled by a separate config file. I've managed something, but I'm not sure I like it. 1/ edit /usr/lib/systemd/scripts/nfs-utils_env.sh and add if [ "$NFS_SECURITY_GSS" == "yes" ]; then SVCGSS_PROG=/usr/sbin/rpc.svcgssd else SVCGSS_PROG=/bin/true fi somewhere before "mkdir -p /run/sysconfig" 2/ add echo "SVCGSS_PROG=$SVCGSS_PROG" in the block of similar commands at the end of that file. 3/ create directory /usr/lib/systemd/system/rpc-svcgssd.service.d and create a file in that directory called "prog.conf" containing [Service] ExecStart= ExecStart=/bin/sh -c "${SVCGSS_PROG} ${SVCGSSDARGS}" 4/ run: systemctl daemon-reload 5/ run: systemctl restart nfs-config.service Now if you "systemctl restart rpc-svcgss" it should not run the daemon (unless NFS_SECURITY_GSS is "yes"). I think I'd rather modify rpc-svcgssd in some what... not sure yet. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c14 --- Comment #14 from Neil Brown --- (In reply to boo35 boo35 from comment #13)

but, this still nags at me as being incorrect

/usr/lib/systemd/system/rpc-svcgssd.service ... ConditionPathExists=/etc/krb5.keytab ...

I think that is definitely correct. If /etc/krb5.keytab is not present, thenre there is no point running the service. The problem is that it isn't sufficient. We want another test - if disabled in config file then don't run it either. systemd doesn't help with that. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=956558 http://bugzilla.opensuse.org/show_bug.cgi?id=956558#c16 --- Comment #16 from Neil Brown --- (In reply to boo35 boo35 from comment #15)

Perhaps too many places for configuration? Yep, asking about the wisdom of /etc/sysconfig/* ...

Good question to ask. I've just posed it on a suse-internal list. Maybe something helpful will arise.

Some comments/approaches for thought

https://coreos.com/os/docs/latest/using-environment-variables-in-systemd- units.html

Evironment variables are clearly useful.

http://0pointer.de/blog/projects/on-etc-sysinit.html

I've seen that. I don't agree.

TBH, I have absolutely _no_ idea of the strategy & thinking @ *Suse of maintaining/deprecating /etc/sysconfig/usage.

Me neither. Maybe I'll find out. -- You are receiving this mail because: You are on the CC list for the bug.