Curly one for me anyway - systemd dependancies on mounts from /etc/fstab

I’ve come across this problem from time to time…

i.e. even though my remote mounts are in /etc/fstab, and do get mounted (eventually, without intervention), services that rely on them won’t startup properly…

e.g. on my Orange Pi +2E running Armbian (essentially boobuntu 16.04 "server"on armhf) - transmission-daemon wouldn’t start via systemd on boot, because the filesystem it needed was an NFS mount that got mounted sometime after systemd tried to start transmission-daemon… I gave up trying to figure that out - I hardly ever reboot it - so when I do reboot it - or lose power - I just SSH to it and run a script to mount the NFS share - THEN - start transmission-daemon…

Just been doing some reading - it looks pretty complicated - creating and configuring systemd unit files for ensuring certain mounts are mounted, and editing the UNIT file for the dependant service, so that it “needs” to have that dependancy UNIT file satisfied…

Anyways - just came across something similar in my job today - on a RHEL system, apache (RHEL family always call it “httpd”, but Debian family nearly always call it “apache2”) - httpd won’t start on boot and much of the default vserver/documentroot in httpd.conf file uses stuff on an NFS share… I guess I need to write a unit file for that and then force httpd to ensure that dependancy is resolved before starting up…

FAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHK ! I sure miss SysV Init sometimes!!!

How much easier was it to either have the one startup script (or two separate scripts) in /etc/init.d/ to

  1. mount dependancy filesystem
  2. start daemon / app / service and fork it to bg

Or even:

  1. /etc/rc.d/rc3.d/S90-mount-my-shite
  2. /etc/rc.d/rc3.d/S99-start-my-shite

The only thing I “like” about systemd is - that it mostly seems to work, and it’s REALLY good at running stuff as a user account (e.g. I run Resilio Sync with “systemctl --user start resilio-sync.service”) - that’s too easy - and I’m scratching my head with perplexity if I try to do something similar on a platform that DOESN’T DO SYSTEMD… hmmm…

1 Like

This RHEL (7.9) server runs a seismic data application server, which can be accessed by users from a desktop application - or - via a browser…

Anyway - the vendor came up with some suggestions which I’m going to try - but I need to wait till I can get some downtime on the web application - basically this line in :

/usr/lib/systemd/system/httpd.service

After=network.target remote-fs.target nss-lookup.target

Needs to become these two lines :

Requires=rpc-statd.service network.target nfs.service nfs-mountd.service local-fs.target remote-fs.target
After=syslog.target network.target nfs.service nfs-mountd.service local-fs.target rpc-statd.service remote-fs.target

But probably can’t get at it again until next Thursday afternoon…

And the engineer from the vendor agrees with me - System V Init “rocked”! :smiley:

1 Like

There does seem to be some strange interaction between systemd and other init systems when these coexist on a multi-boot setup. I have debian 11 with systemd, void with runit, and an old debian8 with init, in a multiboot situation . I have 2 disks. Occasionally when debian11 boots it fails to find a filesystem mounted in fstab. the filesystem is on disk sda and debian11 is on sdb. It goes looking for the filesystem on the wrong disk, and, of course, fails to find it and drops into single user mode. It keeps doing this until I boot void linux, then the problem disappears and i can boot debian 11 again.
I cant see any reason why a boot process would go looking on the wrong disk to mount a partition . It only started doing this when I mixed different init systems in a multiboot setup.
Welcome any suggestions. I realise this is short on details. It would be nice to know whether I have a problem with grub, or with uefi, or with init systems, or with gpt disks.
Regards
Neville