Bugzilla – Bug 735943
If NMB is enabled while booting in systemd on system with several ethernet cards, only the first card gets IP address
Last modified: 2012-10-25 13:37:52 UTC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0.1) Gecko/20100101 Firefox/8.0.1 On an OpenSuSE 12.1 (32-bit and 64-bit) system with more than one ethernet card statically configured with ifup, booting in systemd, enabling the nmb service at startup causes only the first card to get an IP address. The additional cards do not get an IP address, despite being statically configured. This behavior occurs even if nmb is the only service enabled. (It also occurs if it is started in combination with other services.) The problem does not occur if you boot in System V. Reproducible: Always Steps to Reproduce: 1. chkconfig nmb on 2. reboot in systemd 3. ifconfig -a Actual Results: Only the first ethernet card has an IP address allocated Expected Results: All of the ethernet cards have an IP address allocated
Either this is an issue with systemd - adding Frederic to get his input on this - or we have to provide 'native' systemd files for the services Samba offers. We have them already upstream and need to check and merge them to our packages.
there is no reason to require native systemd service file for nmb. Since systemd is agressively parallelising services startup, if network service is not waiting long enough for all ethernet card to be configured, it is not systemd fault. check WAIT_FOR_INTERFACES value in /etc/sysconfig/network/config
Different poster but same machines ... Increasing WAIT_FOR_INTERFACES from 30 to 300 didn't help. In the meantime we experienced the same issue on another machine (64bit, 2 netcards). On the 3 machines, nmb seems to be the bottleneck in systemd: - it takes about 5 minutes for the login prompt to appear. - only the first netcard gets an IP allocated. - However nmb is successfully started. - the value of WAIT_FOR_INTERFACES doesn't affect the boot time. No matter how long it waits for netcards, it takes about 5 minutes to boot - which I guess is the timeout for services in systemd. When nmb is off in systemd: - it boots normally - all netcards get their IP. Thus it is a lot faster to disable nmb at boot and start it manually. I haven't tested nmb on a machine with a single netcard. So I don't know if the problem is nmb itself or the combination of nmb with several netcards. In system V, everything is ok.
hmm, could people try to move /etc/sysconfig/network/if-up.d/21-* away ?
That worked. - Boot is (a lot) faster. - WAIT_FOR_INTERFACES is back to default (30) - All interfaces get an IP. - smb and nmb are started. - samba server is working.
/etc/sysconfig/network/scripts/cifs is causing the problem. I moved the other script back (dhcpcd-hook-samba) and it was still OK.
Created attachment 467289 [details] disables rcnmb start causing systemd to hang for 5 minutes. Commenting out this line allows systemd to boot normally, while all network interfaces get an ip and nmb starts successfully.
I commented out the line causing the problem - as a temporary workaround.
could you try replacing the offending line with systemctl restart --ignore-dependencies nmb.service when booting under systemd ?
That works. It didn't seem to bother when booting in system V ... so far. I read that there were data corruption issues in one way when booting in systemd. I haven't checked that yet. I just make sure that the daemons get started and the NICs get an IP.
I didn't saw ANY data corruption report related with systemd (and this is off topic to this bug report). Bobby, could you do similar test (replace rcnmb start with systemctl restart --ignore-dependencies nmb.service) ?
(In reply to comment #11) > I didn't saw ANY data corruption report related with systemd (and this is off > topic to this bug report). I've no idea how this is related, but bnc#732910 reports overwritten dhclient-script -- the reporter says, it happens only while a systemd boot. Agnelo, do you have a link to the place where you read about data corruption? IMO it is not a problem of network service that does not wait long enough: systemd runs into a deadlock when there are two "systemctl force-reload nmb.service" are running parallel [started by if-up.d/21-dhcpcd-hook-samba]. See also bnc#725503#c10 and bnc#724777#c4.
(In reply to comment #12) > Agnelo, do you have a link to the place where you read about data corruption? > In the network subforum of the openSUSE forum (a sticky post at the top of the page). The site is down since yesterday.
Duplicated of 732395 per comment#4 *** This bug has been marked as a duplicate of bug 732395 ***
(In reply to comment #12) > (In reply to comment #11) > > I didn't saw ANY data corruption report related with systemd (and this is off > > topic to this bug report). > > I've no idea how this is related, but bnc#732910 reports overwritten > dhclient-script -- the reporter says, it happens only while a systemd boot. FYI: It was a bug in dhclient (in a patch), stderr -> /dev/null were marked close-on-exit and thus has been closed while exec of dhclient-script. So a completely unrelated issue.
*** Bug 731630 has been marked as a duplicate of this bug. ***