0

on our centos 8 servers, we have many custom services to start at boot time. To split things between system and "our stuff", we put everything in our path /truc

Thoses services are enabled via a kind of systemctl enable /truc/etc/systemd/machin.service

After a daemon-reload that's ok. In my production context, job is done.

But on dev / QA contexts, /truc is a remote NFS mounting on a file server.

At boot time, /truc doesn't contain services files, so none of them starts

I tried things with After=remote-fs.target or RequiresMountsFor=/truc but, anyway, file is not read has it is not yet present while booting

Any tips / hack ?!

Has this happens on a dev server, I can add a "hack.service" somewhere in the system path. But I cannot move/copy service files outside this NFS mount

thanks

Improve this question
2
  • I guess you'll have to mess with the initramfs so that it makes sure /truc (in the real root sense) is mounted before "switching root". (Some people like to have seperate /usr partition. I guess you can try to find out how is that normally "handled" in the distro you use and see if the approach can apply to your case as well.)
    – Tom Yan
    Mar 9, 2023 at 0:50
  • But I cannot move/copy service files outside this NFS mount Btw I don't get this. Wouldn't you really be touching files (well, I mean, making symlinks) somewhere outside this mount anyway, when you have the services inside enabled?
    – Tom Yan
    Mar 9, 2023 at 1:04

2 Answers 2

Reset to default
2

I needed to manually create a systemd service for my minecraft server instance. There is an option on the service config file (mine was at /etc/systemd/system/mcservice.service) which you can define a delay for it to start. Assuming the service runs as root, you just have to add to the [Service] section the following line (fill in your path):

ExecStartPre=mount -t nfs <IP source>:<remote path> <local path>

After saving the file, you can live test the service by reloading systemctl using:

sudo systemctl daemon-reload

If the service user is not root, or the mounting of the NFS mountpoint is done by other service (which runs as root), you just have to replace the mount command on ExecStartPre by a simple 'sleep 10', for example (adjust time accordingly). Also, you can use the option After and pointing to your NFS mounting service (it will run after it has finished mounting).

Good luck, I hope I have helped.

Improve this answer
2
  • The problem in the OPs case isn't really about "holding back" a service start. Rather it's about the fact that systemd does NOT load a service file just before trying to start it, but more or less, before it tries to start anything. Basically it loads all the (valid) files from the predefined paths and order them, then start them according to the order. And the problem here is that some service files are not there when systemd does this "first step".
    – Tom Yan
    Mar 9, 2023 at 0:58
  • 1
    Btw, even in your case, I think the proper way is to have a mount unit written and rely on dependencies (if you really want to have this kind of "custom automount", I mean; otherwise, probably RequiresMountsFor= as the OP has written)
    – Tom Yan
    Mar 9, 2023 at 1:09
0

Inspired by remarks and comments, as this is for dev/QA servers, I tried to get a "quick & dirty" solution.

in root's crontab, this seems to do the job :

@reboot sleep 30 && /sbin/ldconfig && /bin/systemctl daemon-reload && /bin/systemctl restart machin.service

My first attempt was not good because of ldconfig instead of /sbin/ldconfig

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .