Bug 744399 - Race between Samba service and Network Manager?
Summary: Race between Samba service and Network Manager?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: samba
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 759798 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-08 11:06 UTC by Michael Schwendt
Modified: 2013-03-05 08:59 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-04 17:08:32 UTC


Attachments (Terms of Use)

Description Michael Schwendt 2011-10-08 11:06:12 UTC
Description of problem: 
I'm facing the problem that when booting a DHCP-lease based desktop in the LAN with "interfaces = lo p37p1", the Samba service does not bind to the all addresses interface 0.0.0.0 and only does so after a simple "systemd restart smb.service":

/var/log/boot.log
[...]
Started Network Manager.
Starting RPC bind service...
Starting Samba SMB Daemon...
[...]

# netstat -tpan|grep smb
tcp        0      0 :::445                      :::*                        LISTEN      1019/smbd           
tcp        0      0 :::139                      :::*                        LISTEN      1019/smbd           

$ smbclient '//127.0.0.1/homes'
[...]
Connection to 127.0.0.1 failed (Error NT_STATUS_CONNECTION_REFUSED)

# systemctl restart smb.service
[root@localhost ~]# netstat -tpan|grep smb
tcp        0      0 0.0.0.0:445                 0.0.0.0:*                   LISTEN      1918/smbd           
tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LISTEN      1918/smbd           
tcp        0      0 :::445                      :::*                        LISTEN      1918/smbd           
tcp        0      0 :::139                      :::*                        LISTEN      1918/smbd           

$ smbclient '//127.0.0.1/homes'
[...]
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.0-73.fc16]
smb: \> quit

Version-Release number of selected component (if applicable):
# rpm -qa samba\*
samba-client-3.6.0-73.fc16.x86_64
samba-common-3.6.0-73.fc16.x86_64
samba-3.6.0-73.fc16.x86_64
samba-winbind-clients-3.6.0-73.fc16.x86_64


How reproducible:
Always

Additional information:
This is with SELinux set to permissive (because of current targeted policy's problems with nmbd among others).

Comment 1 Andreas Schneider 2011-10-10 09:33:44 UTC
Do we have networkmanager dispatch scripts to reload the samba and winbind configuration after a restart?

Comment 3 Alfred Glanzer 2011-11-12 08:29:54 UTC
Exactly the same problem here !

FC16, i386, upgrade from FC15.

On every start / reboot, no Samba.

A NetworkManager script solves the problem.

Comment 4 Ivan Grischott 2011-12-09 08:33:44 UTC
Could you send me the NetworkManager script?

Additional Info to reproduce:

i setup 2 maschines (both maschines have 2 NIC's)completly new FC16 with updates.

systemctl status smb.service (active)
systemctl status nmd.service (active)
systemctl status winbind.service (active)

connect to samba share see only empty folders.

if i stop all samba services systemctl stop smb.service etc. maybe kill the PID smbd manually

Start the Samba Service manual with smbd -i .. the shares works fine.

i check the systemd start scripts /lib/systemd/system/smb... but i doesent see a difference. i think a problem could be the NetworkManager or the 2 Network interfaces. i hope this infos are useful. sorry for the breaky english. :-)

Comment 5 Alfred Glanzer 2011-12-09 08:46:06 UTC
Well, the script is very simple.
It's called 15-samba, and is placed in /etc/NetworkManager/dispatcher.d/


#!/bin/sh

case "$2" in
	up|down|vpn-up|vpn-down)
		/bin/systemctl restart smb.service || :
		/bin/systemctl restart nmb.service || :
		;;
esac

Good luck, Alfred.

Comment 6 Ivan Grischott 2011-12-09 09:39:55 UTC
Thank you for the script. 

But my Main Problem is not solved. a restart of the services is not the solution.

if i stop the service with systemctl stop smb.service then start manually with "smbd -i" the share works.. 

messages from the log.smbd:

  Copyright Andrew Tridgell and the Samba Team 1992-2011
[2011/12/09 10:34:02.497715,  0] smbd/server.c:1101(main)
  standard input is not a socket, assuming -D option

thanks for helping..

Comment 7 Andreas Schneider 2011-12-09 12:32:23 UTC
Instead of '/bin/systemctl restart smb.service' you should use 'smbcontrol smbd reload'

Comment 8 Andreas Schneider 2011-12-09 12:35:00 UTC
*** Bug 759798 has been marked as a duplicate of this bug. ***

Comment 9 Alfred Glanzer 2011-12-20 20:51:37 UTC
Similar problem:

Also OpenSWAN (IPSEC) does not startup correctly after boot / reboot.

IPSEC starts before NetworkManager has been able to initialize the external interface. External interface is not seen and cannot be added during startup.

A restart after boot solves this problem.

This can be accomplished by a NetworkManager script.

Comment 10 Eddie Lania 2012-01-01 19:37:57 UTC
This also impact services as:

dhcpd
dhcpd6
arpwatch
clamav-milter
nmb
smb
winbind

etc.

This is, since i've upgraded to FC16.

It seems to me that no network availability at time of starting these services is the source of this problem.
If i login after the start up process and manually (re)start the failed services they do not fail.

Comment 11 Eddie Lania 2012-01-02 12:25:46 UTC
Sorry about comment # 10

I have solved that by executing:

"systemctl enable NetworkManager-wait-online.service"

Which enables starting other services to wait for NetworkManager to be started.

This also helps the smb, nmb and winbind services to start without failing.

Regards,

Eddie.

Comment 12 Eddie Lania 2012-01-15 16:45:22 UTC
Doesn't a "systemctl enable NetworkManager-wait-online.service" solve this problems for any one else than me?

Comment 13 David Downing 2012-01-15 17:05:16 UTC
Works for me.

Comment 14 Jack Greene 2012-08-09 20:45:50 UTC
Thanks for posting the solution Eddie.  I really appreciate you posting it.  I'm surprized this topic isn't closed.

Comment 15 Michael Schwendt 2012-08-10 06:49:17 UTC
Well, Jack, "the solution" is a work-around, but will the packages work by default with Fedora 18, 17, or 16? Or will it be necessary to run the work-around manually?

Comment 16 SpuyMore 2013-01-08 12:59:56 UTC
In Fedora 18 I have the same problem, nmbd and cups won't succesfully start on boot but do start correctly when started later on the command line. I do have NetworkManager-wait-online.service enabled but somehow that doesn't help.

Comment 17 Tim Waugh 2013-01-08 14:54:40 UTC
Dennis Verspuij: could you please file a bug report against cups?  I haven't seen that behaviour here and I'd like to track down what the problem might be.

Comment 18 SpuyMore 2013-01-11 12:51:30 UTC
Hi Tim. I am not sure if nmb and cups are really significant in this problem. I investigated a little further. My system has two NIC's, one for WAN and one for LAN. De NetworkManager-wait-online.service finishes as soon as one of them is (partially) up. Because I specifically bound nmd and cupsd to the LAN network (not their defaults localhost or all interfaces) there is still the chance the LAN is not available yet. And und fortunately that is 100% of the time for me.

A fix would be to be able to configure NetworkManager-wait-online service to wait for a specific interface and addressing type to complete, e.g. eth1 + IPV4. E.g. in a file /etc/sysconfig/NetworkManager-wait-online. I think bug #837793 is very relevant.

(In reply to comment #17)
> Dennis Verspuij: could you please file a bug report against cups?  I haven't
> seen that behaviour here and I'd like to track down what the problem might
> be.

Comment 19 Fedora End Of Life 2013-01-16 10:19:56 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 20 SpuyMore 2013-01-16 10:27:23 UTC
I think this issue is still current so should move to Fedora 18, please see my earlier comments.

Comment 21 Andreas Schneider 2013-03-04 17:08:32 UTC
I've tried to reproduce this with F18 and everything works just fine if smbd listens to 0.0.0.0 (everything).

I've install samba on my notebook and activated it with:

systemctl enable smb.service

Then rebooted the machine. It comes up but no ip addresses assigned. Then I connected to my wifi and after that I was able to access smbd from my desktop machine.

desktop$ smbclient -U% -L //192.168.1.2
Domain=[DISCWORLD] OS=[Unix] Server=[Samba 4.0.3]

        Sharename       Type      Comment
        ---------       ----      -------
        profiles        Disk      Network Profiles Service
        users           Disk      All users
        groups          Disk      All groups
        print$          Disk      Printer Drivers
        guru            Disk      GURU ACL Test
        IPC$            IPC       IPC Service (Samba 4.0.3)

After that I enabled nmbd with:

systemctl enable nmb.service

and rebooted my notebook. I connected to my wifi and looked up the netbios name on my desktop.

desktop$ nmblookup -S krikkit
querying krikkit on 192.168.52.255
querying krikkit on 192.168.178.255
192.168.178.52 krikkit<00>
Looking up status of 192.168.178.52
        KRIKKIT         <00> -         B <ACTIVE> 
        KRIKKIT         <03> -         B <ACTIVE> 
        KRIKKIT         <20> -         B <ACTIVE> 
        DISCWORLD       <00> - <GROUP> B <ACTIVE> 
        DISCWORLD       <1c> -         B <ACTIVE> 
        DISCWORLD       <1e> - <GROUP> B <ACTIVE> 

        MAC Address = 00-00-00-00-00-00


Everything works as expected.

Comment 22 Michael Schwendt 2013-03-04 18:53:42 UTC
Please let's not change history. The original bug report was about F16 in 2011, not about F18. I haven't checked whether the problem was reproducible when F17 (or F18) was released. With F18 I see NetworkManager-wait-online here, but haven't used Samba with F18 yet.

Comment 23 Andreas Schneider 2013-03-05 08:59:44 UTC
Sorry. I didn't need or use NetworkManager-wait-online at all. Everything worked just fine without it.


Note You need to log in before you can comment on or make changes to this bug.