Control: reopen -1
Control: found -1 215-5+b1
On Sun, 14 Sep 2014 17:20:47 +0200 Michael Biebl <[email protected]> wrote:
> I'm going to close this bug for now. If you still encounter any issues
> and you have additional information, please let us know, so we can
> reopen the bug report.
I'm seeing this issue and it seems that others have added more info
since the bug was closed here, hence reopening as suggested.
For my part I'm seeing it on an up to date Jessie system (apt upgrade
this morning) talking to a Wheezy server.
My /etc/network/interfaces is:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
My /etc/fstab contains:
filer01:/srv/exports/music /storage/music nfs
defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys
filer01:/srv/exports/media /storage/media nfs
defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys
filer02:/srv/exports/mythvideo /var/lib/mythvideo nfs
defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5
filer02:/srv/exports/mythtv /var/lib/mythtv/recordings nfs
defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5
On most boots some subset of these do not come up. Before the apt
upgrade this morning I was running 208-8 and the failure was only
intermittent. Since updating to 215-5+b1 I've been seeing at least one
of the mounts failing on each boot. On failure I see:
# systemctl status -l var-lib-mythtv-recordings.mount
● var-lib-mythtv-recordings.mount - /var/lib/mythtv/recordings
Loaded: loaded (/etc/fstab)
Active: failed (Result: exit-code) since Sun 2014-10-19 12:35:04
BST; 3min 53s ago
Where: /var/lib/mythtv/recordings
What: filer02:/srv/exports/mythtv
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 428 ExecMount=/bin/mount -n filer02:/srv/exports/mythtv
/var/lib/mythtv/recordings -t nfs -o
defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5
(code=exited, status=32)
Oct 19 12:35:04 iranon rpc.statd[454]: Version 1.2.8 starting
Oct 19 12:35:04 iranon rpc.statd[454]: Flags: TI-RPC
Oct 19 12:35:04 iranon rpc.statd[454]: failed to create RPC listeners,
exiting
Oct 19 12:35:04 iranon mount[428]: mount.nfs: rpc.statd is not running
but is required for remote locking.
Oct 19 12:35:04 iranon mount[428]: mount.nfs: Either use '-o nolock' to
keep locks local, or start statd.
Oct 19 12:35:04 iranon mount[428]: mount.nfs: an incorrect mount option
was specified
Oct 19 12:35:04 iranon systemd[1]: var-lib-mythtv-recordings.mount
mount process exited, code=exited status=32
Oct 19 12:35:04 iranon systemd[1]: Failed to mount
/var/lib/mythtv/recordings.
Oct 19 12:35:04 iranon systemd[1]: Unit var-lib-mythtv-recordings.mount
entered failed state.
The output is essentially identical in each case.
Running "mount -a" lets everything come up.
rpcbind seems to be running:
# systemctl status -l rpcbind.service
● rpcbind.service - LSB: RPC portmapper replacement
Loaded: loaded (/etc/init.d/rpcbind)
Drop-In: /run/systemd/generator/rpcbind.service.d
└─50-rpcbind-$portmap.conf
Active: active (running) since Sun 2014-10-19 12:35:04 BST; 4min 29s
ago
Process: 434 ExecStart=/etc/init.d/rpcbind start (code=exited,
status=0/SUCCESS)
CGroup: /system.slice/rpcbind.service
└─460 /sbin/rpcbind -w
Oct 19 12:35:04 iranon rpcbind[434]: Starting rpcbind daemon....
The timestamps are very close to the mounts -- so perhaps a race? That
fits in with the observation in message #77 that this is related to
portmap (AIUI rpcbind is the new portmap).
Looking over the bug I think I've supplied the sort of information
you've generally been looking for, if there's anything else you need
though just give a shout.
Cheers,
Ian.
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
