Am 20.11.2014 um 14:03 schrieb Simon McVittie:
On Thu, 20 Nov 2014 at 13:30:58 +0100, Patrick Matthäi wrote:
I can reproduce it on a system, nfs- is not starting on boot.
This might actually be more relevant to nfs-common's existing RC bug
(since you presumably need to have nfs-common installed for this
configuration), but I would rather not attach yet more to that bug
since I think it's already mixing up somewhere between 3 and 5 related
issues.
Please specify your systemd, nfs-common and rpcbind versions,
# dpkg -l|egrep "portmap|rpcbind|nfs-"
ii nfs-common 1:1.2.8-9 amd64 NFS support
files common to client and server
ii nfs-kernel-server 1:1.2.8-9 amd64 support for
NFS kernel server
ii rpcbind 0.2.1-6 amd64 converts RPC
program numbers into universal addresses
the output of:
systemctl status nfs-common.service
systemctl show nfs-common.service
and the same for rpcbind.service, rpcbind.target, paths.target and
basic.target (i.e. the stuff implicated in your dependency loop).
If the "systemctl status" calls list any "Drop-In" files, please also
provide those.
Should I provide them after a reboot (without manual starting the nfs
services) or just while they are running?
If you have local modifications to /etc/init.d/nfs-common,
/etc/init.d/rpcbind and/or /etc/insserv.conf{,.d} please attach those too.
No changes have been made.
The output of "reportbug --template systemd" might also be interesting,
but is rather long and hopefully unnecessary.
Package: systemd
Version: 215-5+b1
....
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-57
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1
ii libblkid1 2.25.2-2
ii libc6 2.19-13
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-3
ii libgcrypt20 1.6.2-4
ii libkmod2 18-3
ii liblzma5 5.1.1alpha+20120614-2+b1
ii libpam0g 1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-5+b1
ii sysv-rc 2.88dsf-57
ii udev 215-5+b1
ii util-linux 2.25.2-2
Versions of packages systemd recommends:
pn dbus <none>
pn libpam-systemd <none>
Versions of packages systemd suggests:
pn systemd-ui <none>
I would also like to know whether you have a non-unified /usr (i.e.
not on the rootfs), or any networked or otherwise unusual filesystems
in fstab. (Just a wild guess, it might not be relevant at all.)
Nothing like that:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/backup--lvl3-root 58G 23G 35G 40% /
udev 10M 0 10M 0% /dev
tmpfs 5.2G 8.8M 5.2G 1% /run
tmpfs 13G 4.0K 13G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 13G 0 13G 0% /sys/fs/cgroup
/dev/sda1 228M 52M 164M 24% /boot
/dev/mapper/lvl3--storage-data 28T 14T 15T 48% /mnt
Nov 20 13:23:56 backup-lvl3 systemd[1]: Cannot add dependency job for unit
display-manager.service, ignoring: Unit display-manager.service failed to
load: No such file or directory.
Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on
basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by deleting
job paths.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Job paths.target/start deleted to
break ordering cycle starting with basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on
basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by deleting
job rpcbind.service/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Job rpcbind.service/start deleted to
break ordering cycle starting with basic.target/start
So this is Very Bad: systemd has found a dependency loop in early boot
(basic.target is approximately equivalent to the earlier parts of rcS.d),
and broken it in an essentially random place because that's somewhat
more likely to succeed than just refusing to continue.
The question is why this dependency loop exists. Presumably, one of
the dependencies is unnecessary or wrong.
I think I might actually have been wrong with the initial report of this
bug: /etc/init.d/rpcbind does not provide $portmap, but
/etc/insserv.conf.d/rpcbind does, and recent(ish) systemd is meant to
respect both. So systemd *should* have already realised that
rpcbind.service (i.e. /etc/init.d/rpcbind) is necessary for rpcbind.target
(i.e. $portmap)... but perhaps "help! I don't know how to disentangle
this dependency loop" trumps that.
S
Good question, I am just learning systemd. There is *one* service (init
service) on this machine which comes not from the Debian repositorie:
vmware-tools (from vSphere 5.1 in version 9.0.13.38765 (build-2126665)).
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
