Slow Boot after adding NFS shares

English Install/Boot/Login
21

Ok i have moved ntp to S99.

I’m still having a slow boot and i’m getting network.service failed (although network is working). There is still a 5 minute delay for something to time out and after that services are going up.

Nov 30 13:55:17 romantsa systemd[1]: network.service operation timed out. Terminating.
Nov 30 13:55:17 romantsa systemd[1]: Unit network.service entered failed state.

romantsa:~ # systemd-analyze time
Startup finished in 5946ms (kernel) + 341837ms (userspace) = 347784ms
romantsa:~ # systemd-analyze blame
 28765ms yastwc.service
 26022ms webmin.service
 24315ms mysql.service
 19791ms smb.service
  5551ms remount-rootfs.service
  5496ms storage-after-cryptsetup.service
  4938ms lvm.service
  4486ms nfsserver.service
  4035ms squid.service
  4028ms bootsplash-startup.service
  3264ms localnet.service
  3264ms systemd-remount-api-vfs.service
  2845ms nmb.service
  1663ms systemd-vconsole-setup.service
  1459ms pure-ftpd.service
  1380ms network-remotefs.service
  1149ms yastws.service
  1111ms mcelog.service
  1006ms snmpd.service
   893ms ddclient.service
   834ms systemd-readahead-replay.service
   821ms deluged.service
   763ms sshd.service
   740ms ntp.service
   731ms cycle.service
   681ms systemd-sysctl.service
   600ms cifs.service
   555ms irq_balancer.service
   514ms deluge-webd.service
   508ms nscd.service
   466ms systemd-readahead-collect.service
   429ms splash.service
   428ms udev.service
   418ms udev-trigger.service
   403ms nfs.service
   364ms dev-mqueue.mount
   352ms dev-hugepages.mount
   324ms media.mount
   315ms sys-kernel-debug.mount
   303ms sys-kernel-security.mount
   301ms rpcbind.service
   298ms systemd-logind.service
   281ms var-lock.mount
   277ms var-run.mount
   222ms auditd.service
   143ms cpufreq.service
   127ms syslog.service
   123ms splash_early.service
   102ms systemd-tmpfiles-setup.service
    97ms bootsplash-quit.service
    88ms systemd-user-sessions.service
    62ms fbset.service
    56ms rc-local.service
    49ms srv.mount
    41ms purge-kernels.service
    31ms console-kit-log-system-start.service
    27ms dbus.service
    19ms acpid.service
22

Don’t know if this will help the OP or not, but nfs causing slow booting was something discussed on the Tumbleweed forum not too long back, it was mainly to do with nfs timing out when using wireless connections but the solution I arrived at might also be of use in the cases described here.

Without going into too much explanation and keeping it simple this it what I did:

Stop nfs services from loading automatically at system boot (disable any nfs services in Yast > System > System Service (runlevel) is a quick and simple way to do this)

Add an entry to /etc/init.d/after.local to start each nfs service you need, example: to start the nfs client just add ‘service nfs start’

The reason this works is that the ‘hang’ is ‘usually’ caused by nfs trying to mount things before the network has had chance to come up properly and the /etc/init.d/after.local file is a script that is automatically called once the network is up. So anything you wish to start once the network is ready can be added here, hope that’s of some use

23

I will try that on the one system that has nfs mounts, but the other one (my home server) that has also very slow boot has no nfs mounts (it has nfs server although), so i think it something more fundamental with systemd that causes the problem.

24

Is there a similar tool for sysvinit?

Thanks

25

On 12/03/2011 08:46 AM, ionmich wrote:
>
> Is there a similar tool for sysvinit?

Yes, it is called bootchart. It is not normally installed.

26

Ecky wrote:
> Stop nfs services from loading automatically at system boot (disable
> any nfs services in Yast > System > System Service (runlevel) is a quick
> and simple way to do this)

NO, NO, NO! This is a bad way to solve the problem.

> Add an entry to /etc/init.d/after.local to start each nfs service you
> need, example: to start the nfs client just add ‘service nfs start’

You shouldn’t need to write one-off custom scripts like this and also
end up with non-standard NFS initialisation. Fix the problem at source
instead of bodging around it!

> The reason this works is that the ‘hang’ is ‘usually’ caused by nfs
> trying to mount things before the network has had chance to come up
> properly

That is correct. And that is why mount(8) has a standard option:

_netdev
The filesystem resides on a device that requires network access
(used to prevent the system from attempting to mount these filesystems
until the network has been enabled on the system).

You must set _netdev on all NFS mounts.

So RTFM, don’t roll your own weirdness when there’s already an answer.

27

On 2011-12-05 12:58, Dave Howorth wrote:
> Ecky wrote:

> _netdev
> The filesystem resides on a device that requires network access
> (used to prevent the system from attempting to mount these filesystems
> until the network has been enabled on the system).
>
> You must set _netdev on all NFS mounts.

But then you still need to attempt mounting them later on.

Is all this reported in Bugzilla? Otherwise, it will not be ever repaired.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

28

On 2011-11-22 23:06, inozemcew wrote:
>
> Problem is that remote-fs.target in systemd ties to mount nfs shares
> before rpc daemons has started.
> Quick fix - use nfs.service
> systemctl disable remote-fs.target
> systemctl enable nfs.service

Is all this reported in Bugzilla? Otherwise, it will not be ever repaired.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

29

On 2011-11-18 14:06, jmdl wrote:

> I have tried as you have suggested i.e. switched to Network Manager
> from the Traditional method and then Turned off run level 3 for NFS
> client.

You can not use network manager and attempt to mount nfs shares during boot.

> Unfortunatley this did not change anything.

Of course not.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

30

Carlos E. R. wrote:
> On 2011-12-05 12:58, Dave Howorth wrote:
>> Ecky wrote:
>
>> _netdev
>> The filesystem resides on a device that requires network access
>> (used to prevent the system from attempting to mount these filesystems
>> until the network has been enabled on the system).
>>
>> You must set _netdev on all NFS mounts.
>
> But then you still need to attempt mounting them later on.

What are you talking about? The system will automatically try the mount
after the network comes up. That’s the whole point.

> Is all this reported in Bugzilla? Otherwise, it will not be ever repaired.

Is what reported in bugzilla. What do you think needs to be repaired? A
user has omitted an option from one of his lines in /etc/fstab and he
needs to fix that omission. There’s nothing broken.

Or do you see something I’m missing?

31

On 2011-12-05 15:44, Dave Howorth wrote:
> Carlos E. R. wrote:

>> But then you still need to attempt mounting them later on.
>
> What are you talking about? The system will automatically try the mount
> after the network comes up. That’s the whole point.

My understanding is that “_netdev” skips mounting those entries, not that
it delays till network is available.

>> Is all this reported in Bugzilla? Otherwise, it will not be ever repaired.
>
> Is what reported in bugzilla. What do you think needs to be repaired? A
> user has omitted an option from one of his lines in /etc/fstab and he
> needs to fix that omission. There’s nothing broken.

That systemd delays for a minute and systemv doesn’t.

And, if that option is needed, yast must do it. Not the user.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

32

On 12/5/2011 2:38 PM, Carlos E. R. wrote:
> On 2011-12-05 15:44, Dave Howorth wrote:
>> Carlos E. R. wrote:
>
>
>>> But then you still need to attempt mounting them later on.
>>
>> What are you talking about? The system will automatically try the mount
>> after the network comes up. That’s the whole point.
>
> My understanding is that “_netdev” skips mounting those entries, not that
> it delays till network is available.
>
>
<snip>
>
>
Carlos E. R.;

For both cifs and nfs mounts in fstab, _netdev only delays the mount until the network is
established. There would be no need of that parameter if it only skipped the mount, since that is
what will happen in its absence.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

33

Carlos E. R. wrote:
> My understanding is that “_netdev” skips mounting those entries, not that
> it delays till network is available.

Evidently you don’t actually use NFS then. :slight_smile:

>>> Is all this reported in Bugzilla? Otherwise, it will not be ever repaired.
>> Is what reported in bugzilla. What do you think needs to be repaired? A
>> user has omitted an option from one of his lines in /etc/fstab and he
>> needs to fix that omission. There’s nothing broken.
>
> That systemd delays for a minute and systemv doesn’t.

systemv certainly does delay if you have chosen the particular set of
(incorrect) options that cause that circumstance. Don’t ask me how I
know that! If you think there is a bug, you will need to be extremely
specific about the circumstances that cause it.

> And, if that option is needed, yast must do it. Not the user.

In my experience, the problem most often arises when somebody has an old
system (from before when _netdev was used) and upgrades it, or else when
somebody copies fstab lines from an old system to a new system. In both
cases, the user needs to be aware of the issue; YaST is just doing what
it’s told. In an ideal world, perhaps there could be code to spot
unusual combinations of options and prompt the user to check them, but
that would be a maintenance nightmare and so might actually increase the
likelihood of bugs (think how many filesystem type-specific options
there are).

If YaST is misbehaving in other circumstances, you will again need to be
very specific about what those circumstances are when reporting the
problem in order to be able to reproduce and fix the problem.

I jumped into this thread precisely because there seemed to be muddled
information being injected into the ‘wisdom of crowds’. We need to be
cautious about making assertions.

34

Thank you. I had used it before but could not remember the name. What about the delays after KDE user login? Is there any way to chart those?

35

On 2011-12-06 12:03, Dave Howorth wrote:
> Evidently you don’t actually use NFS then.

I do. And I used YaST to do it, and YaST did not add that option.
However, I mount manually, not on boot.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

36

On 12/06/2011 09:48 AM, Carlos E. R. wrote:
> On 2011-12-06 12:03, Dave Howorth wrote:
>> Evidently you don’t actually use NFS then.
>
> I do. And I used YaST to do it, and YaST did not add that option.
> However, I mount manually, not on boot.

I recently changed all my NFS mounts to autofs, which mounts them when needed.
For me, that is a lot more satisfactory than either mounting at boot or manually.

37

Larry Finger wrote:
> On 12/06/2011 09:48 AM, Carlos E. R. wrote:
>> On 2011-12-06 12:03, Dave Howorth wrote:
>>> Evidently you don’t actually use NFS then.
>>
>> I do. And I used YaST to do it, and YaST did not add that option.
>> However, I mount manually, not on boot.
>
> I recently changed all my NFS mounts to autofs, which mounts them when
> needed. For me, that is a lot more satisfactory than either mounting at
> boot or manually.

Yes, that’s a possibility. I haven’t done it because when needed may
very often be in the middle of the night on my systems, and I’d rather
be told something’s broken during the day when I’m standing there, which
is when most reboots occur. But autofs is a lot more sensible for a m/c
serving a bunch of home directories, for example.

38

If the slow boot occurs when not connected to a network where the NAS resides, the delay may be that the computer is waiting for a timeout in nfs as it tries to connect. There’s an option in config (don’t recall where, but I found it in the OpenSuse forums) that let’s you shorter the wait to, say, 5 or 10 seconds. j