You are not logged in.
Hi, today found some spare time to make the switch to systemd.
Nearly everything went fine (thanks to the incredible wiki) with two exceptions:
I have two NFS mounts and one of them sometimes fails to mount. They both use the same options:
192.168.0.7:/volume1/thomas /home/thomas/DiskStation/Thomas nfs rsize=32768,wsize=32768 0 1
192.168.0.7:/volume1/public /home/thomas/DiskStation/public nfs rsize=32768,wsize=32768 0 1Here's the part of journalctl:
SnipThe other problem is that even when two mounts work right from the start it takes a very long time until KDM starts, even there're no units that failed to start (systemctl --failed gives no unit).
The red entry I found in the journalctl is this:
Oct 15 11:57:33 kdm[545]: :0[545]: PAM unable to dlopen(/usr/lib/security/pam_permit.s): /usr/lib/security/pam_permit.s: cannot open shared object
Oct 15 11:57:33 kdm[545]: :0[545]: PAM adding faulty module: /usr/lib/security/pam_permit.sLast edited by Barghest (2018-07-09 20:20:10)
Offline
Can you try the nfs-utils package from [testing], please? You also need the rpc.idmapd.service for nfs4 and rpc.statd for nfs3.
Offline
Hi brain0,
I did both things you suggested and since the last three booting processes mounting the two shares went fine. Because I did everything at the same time I don't know which of your points solved it, though :b
Now the second problem still exists: It takes ages until KDM loads when I'm on the systemd boot screen.
Just found out about systemd-analyze blame:
$ systemd-analyze blame
60570ms home-thomas-DiskStation-Thomas.mount
60570ms home-thomas-DiskStation-public.mount
3414ms wicd.service
905ms systemd-modules-load.service
810ms systemd-vconsole-setup.service
783ms systemd-logind.service
677ms systemd-remount-fs.service
606ms dev-mqueue.mount
593ms udisks2.service
561ms systemd-udevd.service
560ms dev-hugepages.mount
546ms sys-kernel-debug.mount
466ms systemd-udev-trigger.service
457ms colord.service
372ms home.mount
336ms systemd-sysctl.service
316ms dev-sda7.swap
294ms rpc-idmapd.service
284ms colord-sane.service
223ms console-kit-log-system-start.service
191ms rpcbind.service
171ms console-kit-daemon.service
160ms tmp.mount
159ms rc-local.service
99ms systemd-tmpfiles-setup.service
89ms var-lib-nfs-rpc_pipefs.mount
69ms home-thomas-Multimedia.mount
59ms upower.service
29ms udisks.service
26ms systemd-user-sessions.service
0ms sys-fs-fuse-connections.mountLast edited by Barghest (2012-10-15 13:44:04)
Offline
Both solved it: Enabling rpc-statd allows nfs3, and installing the testing from package makes sure the ordering is okay and statd actually runs in time.
About the boot time: I had the experience that nfs3 mounts take very long, maybe adding 'vers=3' to fstab makes it faster. What made everything faster for me was making the nfs server nfs4-ready (early versions of nfs4 suck though, due to the whole fsid=0 "master share" mess which is obsolete now).
Either way, you can speed up your boot by adding 'x-systemd.automount' to fstab for the NFS shares - this way, systemd will create an automount point. It will continue booting, and once you try to access the mount points, the application will hang until the mount has finished. Unless you add 'noauto', the file systems will still be mounted on boot, but systemd will not wait until they finish.
Offline
Yes, with 'x-systemd.automount' booting is much faster, but KDE is unresponsive for some time (I assume now it is waiting for the NFS mounts).
With initscripts the whole nfs daemons were started in the background (@) and I didn't experience such a delay. Nevertheless, I guess I can live with it. Thanks again!
Offline