Heya,
Previously running 2.2.3 I was able to deploy afanasy via a centrally installed NFS mount symlinked to /opt/cgru.
Since version 2.3.1 has shifted to systemd, it seems that i'm unable to run the same scam, since the unit file must reside on a filesystem available at PID1.
AFAIK, this is not a dependency/order to service startup issue, but a hard requirement.
Does anyone have any insight?
G
ps: the primary reason for central deployment is having to modify one set of config files, once... rather then having unique files for each machine.
afrender.service on NFS mount
afrender.service on NFS mount
--
Rocky Linux 8.5, cgru 3.2.1
Rocky Linux 8.5, cgru 3.2.1
Re: afrender.service on NFS mount
For posterity, I was able to hack around this by relocating the service file to a local drive, and repointing the symlink to it... but it's kinda bleh.
A more elegant solution would be awesome.
G
A more elegant solution would be awesome.
G
--
Rocky Linux 8.5, cgru 3.2.1
Rocky Linux 8.5, cgru 3.2.1
Re: afrender.service on NFS mount
Hi.
Everything is normal.
You deploy Afanasy in any custom way.
You can write any own init.d/systedm.d service or modify existing.
For example, i am not using a nfs share for binaries.
And we have such /opt/cgru/config.json:
And /cg/tank is our (nfs) shared tools/scripts/configs location.
Everything is normal.
You deploy Afanasy in any custom way.
You can write any own init.d/systedm.d service or modify existing.
For example, i am not using a nfs share for binaries.
And we have such /opt/cgru/config.json:
Code: Select all
{"cgru_config":{
"include":["/cg/tank/config.json"],
"":""
}}
Timur Hairulin
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
Re: afrender.service on NFS mount
Heya Timur,
As you pointed out, everything is normal.
What I didn't know ahead of this process (that I know now) is that service unit files for systemd MUST live on a local file system due to some internal caching/dependency build mechanism.
Basically, if I host the unit files on a remote drives, the system can't see it at boot, and the service fails to start - and it's not simply a matter of waiting for the remote drive to be mounted.
see here: https://github.com/systemd/systemd/issues/8307
G
As you pointed out, everything is normal.
What I didn't know ahead of this process (that I know now) is that service unit files for systemd MUST live on a local file system due to some internal caching/dependency build mechanism.
Basically, if I host the unit files on a remote drives, the system can't see it at boot, and the service fails to start - and it's not simply a matter of waiting for the remote drive to be mounted.
see here: https://github.com/systemd/systemd/issues/8307
G
--
Rocky Linux 8.5, cgru 3.2.1
Rocky Linux 8.5, cgru 3.2.1