Bug 567865

The INIT INFO part of the smbfs (cifs for post 11.2 systems) ensures the network get started before and stopped after the smbfs or cifs service.

Please check the order of the symbolic links named /etc/init.d/rc*.d/K*

On a 11.2 system I see for example:

gab:~ # ls -l /etc/init.d/rc5.d/K*{smbfs,network}
lrwxrwxrwx 1 root root  8  4. Jan 10:44 /etc/init.d/rc5.d/K05smbfs -> ../smbfs
lrwxrwxrwx 1 root root 10 11. Nov 20:09 /etc/init.d/rc5.d/K08network -> ../network

or on Factory it's:

giles:~ # ls -l /etc/init.d/rc5.d/K*{cifs,network}
lrwxrwxrwx 1 root root  7  4. Jan 10:52 /etc/init.d/rc5.d/K01cifs -> ../cifs
lrwxrwxrwx 1 root root 10  2. Nov 16:56 /etc/init.d/rc5.d/K08network -> ../network

In both cases the order of the symbolic links is correct.

Please keep in mind that the actual values following the K might be different on your system as they are calculated dynamically.

I fear that we here face an issue of NetworkManager (NM).  NM might get stopped by the X11 session (KDE or Gnome for example) as the user decided to log off.

@Diederik: Please check the values of the symbolic links.  If they fit to the explanation offered here we have to consult the NM maintainer next.

Hi,

smbfs is failing on shutdown because:
- Networkmanager ist stopped before smbfs
- network-remotefs is stoped before smbfs

lape:/etc/init.d/rc3.d # ls -1
K01auditd
K01bluez-coldplug
K01courier-authdaemon
K01cron
K01fam
K01irq_balancer
K01nscd
K01random
K01smartd
K01splash
K01splash_early
K01sshd
K01stoppreload
K01SuSEfirewall2_setup
K01xinetd
K02acpid
K02alsasound
K02avahi-daemon
K02courier-imap
K02cups
K02fbset
K02kbd
K02postfix
K03network-remotefs
K04haldaemon
K04nfs
K04smbfs
K05rpcbind
K06syslog
K07earlysyslog
K07network

I think network-remotefs and NetworkManager should be stopped after smbfs.
Chris

Solution that works:

lape:/etc/init.d # diff -ruN ~/network-remotefs network-remotefs 
--- /root/network-remotefs      2009-12-18 01:47:48.000000000 +0100
+++ network-remotefs    2010-01-13 00:20:56.000000000 +0100
@@ -26,9 +26,9 @@
 #
 ### BEGIN INIT INFO
 # Provides:            network-remotefs
-# Required-Start:      $network $remote_fs haldaemon
+# Required-Start:      $network haldaemon
 # Should-Start:
-# Required-Stop:       $network $remote_fs haldaemon
+# Required-Stop:       $network haldaemon
 # Should-Stop:
 # Default-Start:       2 3 5
 # Default-Stop:

and

lape:/etc/init.d # diff -ruN ~/smbfs smbfs
--- /root/smbfs 2009-10-27 09:16:52.000000000 +0100
+++ smbfs       2010-01-13 00:21:17.000000000 +0100
@@ -25,9 +25,9 @@
 #
 ### BEGIN INIT INFO
 # Provides:       smbfs
-# Required-Start: $network $syslog
+# Required-Start: $network $syslog network-remotefs
 # Should-Start:   nmb
-# Required-Stop:  $network $syslog
+# Required-Stop:  $network $syslog network-remotefs
 # Should-Stop:    nmb
 # Default-Start:  3 5
 # Default-Stop:   0 1 2 6

then smbfs is umounted without problem when shutdown.
Chris

Tanks Chris for the input on this.

But wouldn't it fir better to add network-remotefs to Should-Start and Should-Stop?  Only then it#s possible to disable the network-remotefs if it's not needed or the user likes to disable it.

See also
https://bugzilla.novell.com/show_bug.cgi?id=487190#c7
that seems to provide a workaround setup here for fs != /usr (insserv
-r smbfs, it will get restarted via NM dispatcher).

We have /usr on nfs requirement and the above changes are wrong.

The use of the nfs/smbfs via /etc/init.d/{smbfs,nfs} are not supported
on wlan interfaces (in ifup mode), because the scripts provide /usr
and all wlan utils as well as the NetworkManager itself are installed
in /usr.

The network-remotefs requires $remote_fs, because it is using tools
from /usr, so removing $remote_fs from network-remotefs or adding
network-remotefs to smbfs adding is wrong.
Also adding network-remotefs to Should-Start/Stop in smbfs is wrong.

The /etc/sysconfig/network/if-{down,up}.d/* scripts are called with
the "-o nm" option that can be used e.g. to disable them in NM mode.

I can also disable the execution of the if-{up,down} scripts in NM
mode completely (remove /etc/NetworkManager/dispatcher.d/netcontrol*)
in stable -- I think this makes sense.

Any smbfs or nfs mounts in NetworkManager mode have to be done using
NM mechanisms. See also bug 487190#c7, bug 557836#c3 and bug 557836#c5.

BTW: See also "man 5 ifservices" - this mechanism is the way in ifup mode.

yes, Marius is completely right with comment #5.

my workaround for this bug (see bug 487190 comment 9) ONLY works for situations, with the following conditions:
1. /usr is on local disc.
2. NetworkManger is used
3. CIFS shares are used/needed

but in this scenario it works perfectly and solves the problem this bug is all about.

i also tried before to solve the problem with changing dependencies/requirements of the init-scripts, but that did not work properly and is really wrong.

@Lars:
My links are:

$ ls -l /etc/init.d/rc5.d/K*{smbfs,network}
lrwxrwxrwx 1 root root  8 jul 29 12:57 /etc/init.d/rc5.d/K04smbfs -> ../smbfs
lrwxrwxrwx 1 root root 10 jul 29 12:57 /etc/init.d/rc5.d/K07network -> ../network


Actually my network is already closed when I logout of KDE. Plasma gets killed, and so does the KDE network manager applet.

*** Bug 584095 has been marked as a duplicate of this bug. ***

Passing this issue to Suresh, the kernel cifs maintainer.  The mounts.cifs helper applications soon will also get separated from the Samba packages anyhow.

Does the suggestion provided in Comment #5 help?

Ping!

(In reply to comment #12)
> Ping!

Sorry, been away for a while. I don't really get the solution of comment #5, and reading it does not make it sound related to my situation, which is:

- When I boot:
  * once the network is up, /mnt/nas/SomeShare is mounted using /etc/init.d/smbfs
- When I shutdown:
  * KDE exits, the NM applet is killed.
  * Connection is lost, /etc/init.d/smbfs stop does not run yet however.
  * At shutdown, the init scripts try to tear down the smbfs connections.
  * The shutdown procedure waits 2 minutes for a timeout..

(In reply to comment #13)
> (In reply to comment #12)
> > Ping!
> 
> Sorry, been away for a while. I don't really get the solution of comment #5,
> and reading it does not make it sound related to my situation, which is:
> 
> - When I boot:
>   * once the network is up, /mnt/nas/SomeShare is mounted using
> /etc/init.d/smbfs
> - When I shutdown:
>   * KDE exits, the NM applet is killed.
>   * Connection is lost, /etc/init.d/smbfs stop does not run yet however.
>   * At shutdown, the init scripts try to tear down the smbfs connections.
>   * The shutdown procedure waits 2 minutes for a timeout..

the solution from comment #5 is described in bug 487190#c7.
you should NOT use /etc/init.d/smbfs!
disable it using: insserv -r smbfs

and instead use networkmanager dispatcher script /etc/NetworkManager/dispatcher.d/smbfs.
this script can be made by copying /etc/NetworkManager/dispatcher.d/nfs and changing it.
here it is ready-to-use as attachment from bug 487190:
https://bugzilla.novell.com/attachment.cgi?id=336364

but this only works when:
1. /usr is on local disc.
2. NetworkManger is used

but i assume this is the case for you, Diederik, right?

(In reply to comment #14)
> the solution from comment #5 is described in bug 487190#c7.
> you should NOT use /etc/init.d/smbfs!
> disable it using: insserv -r smbfs
> 
> and instead use networkmanager dispatcher script
> /etc/NetworkManager/dispatcher.d/smbfs.
> this script can be made by copying /etc/NetworkManager/dispatcher.d/nfs and
> changing it.
> here it is ready-to-use as attachment from bug 487190:
> https://bugzilla.novell.com/attachment.cgi?id=336364

I've tried this solution, it merely moves the problem.

Mounting works properly after being connected. Unmounting happens too late.

Unmounting happens when the connection is already closed. For example
 * When selecting a different network to connect to
 * When closing/killing the network manager applet.

So there is a umount.cifs being stale for each of my connected shares. After ~1 minute it's timed out, and the mount is removed. Then it continues with the next mounted share, up till all 5 I have..


> but this only works when:
> 1. /usr is on local disc.
> 2. NetworkManger is used
> 
> but i assume this is the case for you, Diederik, right?

Yes, I'm using a pretty standard openSUSE install on a laptop. Hence the NetworkManager stuff, because I'm mostly connected with WiFi, even at home. Here, I auto-mount my NAS network shares via smbfs/cifs.

(In reply to comment #15)
> (In reply to comment #14)
> > here it is ready-to-use as attachment from bug 487190:
> > https://bugzilla.novell.com/attachment.cgi?id=336364
> 
> I've tried this solution, it merely moves the problem.
> 
> Mounting works properly after being connected. Unmounting happens too late.
> 
> Unmounting happens when the connection is already closed. For example
>  * When selecting a different network to connect to
>  * When closing/killing the network manager applet.

yes, but these situations are not happening as often as a shutdown.
so it is better to have the timeouts happen in these situations than in a shutdown.

i never noticed the timeouts or too late unmountings since i use the networkmanager-dispatcher-script.

but i usually also don't kill networkmanager during work, nor do i switch networks.

but, of course, the umounts should be done correctly, even if network is switched or networkmanager applet gets killed.

> NetworkManager stuff, because I'm mostly connected with WiFi, even at home.
> Here, I auto-mount my NAS network shares via smbfs/cifs.

and you switch networks at home also?

It appears to me that here cifs cannot do much (without side-effects) and the problem is pretty much the same with other network filesystems. Either Network Manager should handle it, if not we should explain what is possible and close this.

(In reply to comment #16)
> (In reply to comment #15)
> > Unmounting happens when the connection is already closed. For example
> >  * When selecting a different network to connect to
> >  * When closing/killing the network manager applet.
> 
> yes, but these situations are not happening as often as a shutdown.
> so it is better to have the timeouts happen in these situations than in a
> shutdown.

When a shutdown is initiated, the network manager applet is closed once KDE (or GNOME) exists. So for every shutdown, the connection is closed before any init.d script runs.

> > NetworkManager stuff, because I'm mostly connected with WiFi, even at home.
> > Here, I auto-mount my NAS network shares via smbfs/cifs.
> 
> and you switch networks at home also?

Only plugging in an ethernet cable every now and then. I was mainly listing all possible scenario's where the connection is dropped before any unmount script runs.

(In reply to comment #19)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > Unmounting happens when the connection is already closed. For example
> > >  * When selecting a different network to connect to
> > >  * When closing/killing the network manager applet.
> > 
> > yes, but these situations are not happening as often as a shutdown.
> > so it is better to have the timeouts happen in these situations than in a
> > shutdown.
> 
> When a shutdown is initiated, the network manager applet is closed once KDE (or
> GNOME) exists. So for every shutdown, the connection is closed before any
> init.d script runs.

yes. but that is not a problem any more.
there is no init.d script anymore dealing with smbfs.
because i disabled /etc/init.d/smbfs in rc5.d.
so the only umounting of all the smb/cifs-shares happens, when networkmanager is quit.
and at this time the shares are there and can be umounted.
so no hang or timeout anymore and shares become umounted without any problems.

Seems this bug can be closed?

whould be ok for me.

See comments 21/22 - closing as fixed as suggested