https://bugzilla.novell.com/show_bug.cgi?id=744293 https://bugzilla.novell.com/show_bug.cgi?id=744293#c12 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |koenig@linux.de --- Comment #12 from Marius Tomaschewski <mt@suse.com> 2012-02-02 12:05:12 UTC --- (In reply to comment #8)
(In reply to comment #3)
Do you have an DHCPv6 server in your network or only DHCPv4?
no, only v4
When you don't have DHCPv6 server, change to use BOOTPROTO=dhcp4 in /etc/sysconfig/network/ifcfg-eth0 -- this will speed up the network start / cause to not wait for DHCPv6.
ok, I'll change that. but (a) it should work anyway and (b) that small speedup should be no significant help if you check the timestamps in my syslog output...
Yes, you're right -- it should work anyway and under sysvinit it does, as everything else :-) This were just a try to minimize the times and skip unneeded steps.
It looks like systemd would start vdr after network, but would not wait until it finished...?
maybe it only waits for the "lo" device setup being finished ?! that's at least the sequence which syslog shows. maybe lo-setup is just "too fast" doesn't let vdr pass ?!?
Even I can reproduce some of the problems from time to time, they never happened with enabled debug :-/
The error message is:
Jan 31 17:45:45 t3 vdr: [1141] ERROR: /var/spool/video: No such file or directory
this means that the mount-point is not there, so nfs script can't even mount the nfs export.
vdr shall not start before NFS is available. period.
sure.
once NFS is up, that directory exists (as a later successfull "rcvdr start" proofs)
Please fix it using:
mkdir /var/spool/video
NAK: /var/spool/video is a symlink pointing into the NFS share:
lrwxrwxrwx 1 koenig root 26 Jan 19 08:39 /var/spool/video -> /data.hps/video.m2.3/video
# df /data.hps/video.m2.3/video Filesystem 1K-blocks Used Available Use% Mounted on hps1:/t2 5768579072 1460928512 4014623744 27% /data.hps
Ah... OK.
(In reply to comment #5)
Harald, are you using autofs to mount it or nfs script? Can you provide the fstab entry / autofs config please?
nothing magic, just plain fstab. voila (using nfs3 aka nfs makes no difference, just in case... ;-)
# grep data /etc/fstab hps1:/t2 /data.hps nfs4
Is hps1 defined with IP address in /etc/hosts ?
please have another look into my syslog messages and the timetamps (selected line in original sequence):
17:45:45 t3 vdr: [1141] ERROR: /var/spool/video: No such file or directory 17:45:45 t3 ifup: eth0 device: Intel Corporation 82573E Gigabit Ethernet Con 17:45:46 t3 kernel: [ 17.380683] ADDRCONF(NETDEV_UP): eth0: link is not ready 17:45:50 t3 kernel: [ 20.586734] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
vdr starts even before "ifup eth0", and way before "link becomes ready", no way this can be fixed by e.g. not waiting for dhcpv6;)
Yes. (In reply to comment #11)
(In reply to comment #10)
NAK: no change:-(
just to be sure I did a reboot with "init=/sbin/sysvinit" and here the vdr startup works fine *after* eth0/nfs. here is some syslog blurb for the timing:
Yes, as expected. I've installed a test box that I can "stress" and will try to reproduce it with nfs and vdr [I've a DBV card somewhere here too ;)]. We'll see. But before I rewrite the network script once again ;), lets verify some another known issues with systemd: 1) Please verify that this is not same problem as in Bug 724777: The samba-client package installs some hooks, that trigger two "systemctl" commands for one service at same time, what causes a kind of deadlock in systemd that needs a lot of time to recover. There is a workaround in: http://download.opensuse.org/repositories/home:/fcrozat:/systemd/openSUSE_12... You can also move the hooks away: /etc/sysconfig/network/if-down.d/21-cifs /etc/sysconfig/network/if-down.d/21-dhcpcd-hook-samba /etc/sysconfig/network/if-up.d/21-cifs /etc/sysconfig/network/if-up.d/21-dhcpcd-hook-samba 2) Try if this happens with enabled debug and/or disabled resume from swap: First, reboot and add the "systemd.log_level=debug systemd.log_target=kmsg" boot options When it still happens, please attach logs & dmesg output. Further, set also the "noresume" and remove the "resume=..." boot option. Please attach the logs / dmesg output when the problem still occurs. At least my _impression_ is, that some "optimized paths" are used when resume is active... 3) Further, try out if disabling of ntp makes any difference Disable it also the "ntp-runtime" module in /etc/sysconfig/network/config, removing the module name from NETCONFIG_MODULES_ORDER variable. The reason may be as above + yast2 may add e.g. 2.opensuse.pool.ntp.org as server to /etc/ntp.conf, that resolves also with IPv6 addresses and ntp is trying then to sync time with, even there is no IPv6 connectivity what causes at least long timeouts and delays some actions. ntp starts after network, but it caused at least more complications in my tests... inclusive SEGV as in bug 739931. -> Just to verify that ntp is not involved in this problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.