Bug#805167: "Regression: rpcbind doesn't start at boottime on systemd controlled machines."

2016-02-05 Thread Elimar Riesebieter
Control: affects -1 nfs-common



-- 
 Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)



Bug#805167: "Regression: rpcbind doesn't start at boottime on systemd controlled machines."

2016-01-26 Thread Patrik Flykt

> Can I add that the problem also exists on my machine, with nfs-common and 
> autofs as the 
> dependent services?
> 
> My home directories are automounted from an NFS server, but lately I have to 
> manually 
> restart rpcbind and nfs-common before my NFS client finally connects. Reading 
> the 
> output of systemctl status nfs-common shows that nfs-common fails to 
> correctly start 
> because rpcbind isn't running, and just restarting nfs-common does nothing 
> for rpcbind.

On my machine I discovered this in the logs:
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found ordering cycle on 
nfs-common.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.target/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.socket/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
sysinit.target/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
nfs-common.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Breaking ordering cycle 
by deleting job rpcbind.target/start
Jan 26 14:40:14 xx systemd[1]: rpcbind.target: Job rpcbind.target/start 
deleted to break ordering cycle starting with nfs-comm

Since DefaultDependencies is not disabled, rpcbind.socket ends up
depending on sysinit.target. From the above one can see a cycle forming,
which is (correctly) solved by throwing out one of the offending units.

DefaultDependencies should be set to 'no' for early boot, as is the case
for the provided rpcbind.service file. Also rpcbind.socket needs to be
updated with these, i.e. by modifying the following lines in its unit
section:

[Unit]
DefaultDependencies=no
Conflicts=shutdown.target
Before=shutdown.target
After=systemd-tmpfiles-setup.service

The easiest way of applying the modification is to add the above lines
to a .conf file in the /etc/systemd/system/rpcbind.socket.d/ directory.

This solved my problem of unmounted krb5p secured NFS /home and other
directories on bootup.

HTH.



Bug#805167: "Regression: rpcbind doesn't start at boottime on systemd controlled machines."

2016-01-05 Thread Mart van de Wege
Package: rpcbind
Version: 0.2.3-0.2
Followup-For: Bug #805167

Can I add that the problem also exists on my machine, with nfs-common and 
autofs as the 
dependent services?

My home directories are automounted from an NFS server, but lately I have to 
manually 
restart rpcbind and nfs-common before my NFS client finally connects. Reading 
the 
output of systemctl status nfs-common shows that nfs-common fails to correctly 
start 
because rpcbind isn't running, and just restarting nfs-common does nothing for 
rpcbind.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rpcbind depends on:
ii  init-system-helpers  1.24
ii  initscripts  2.88dsf-59.2
ii  insserv  1.14.0-5
ii  libc62.21-6
ii  libsystemd0  228-3
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20150917

rpcbind recommends no packages.

rpcbind suggests no packages.

-- no debconf information