Timeline for systemd services fail with User= in service file
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13, 2019 at 15:12 | comment | added | BobP | Yes, makes sense. Thank you again. | |
| Aug 12, 2019 at 20:54 | comment | added | filbranden |
It's fine if you have one or more scripts involved in starting the daemon process, but you want each of them to run the next step using exec, so that at the end of the chain you end up with the daemon program running under the initial PID, and no shell script is left around. That's the ideal scenario. Does that make sense?
|
|
| Aug 12, 2019 at 20:52 | comment | added | filbranden |
The Type=forking services support "forking daemons", which typically launch a background process (fork, sometimes fork twice) and the main process doesn't stick around, it exits once the daemon is running in background... If you have scripts that fork a daemon, if the script sticks around and "waits" for the daemon to exit, that's more of a Type=simple service... But in that case systemd will interact with the script and not the daemon, so when you stop the service it will kill the script (which should trap signals and possibly forward them to the daemon process.)
|
|
| Aug 12, 2019 at 20:04 | comment | added | BobP | Thank you for the comments and guidelines, filbranden. A lot here to consider moving forward. First step was to get past the errors I was seeing. This was all started because on newer distributions of both Redhat and SuSE, the systemd-sysv-generator seemed not to be quite working, so I decided to go ahead and bite the bullet and get our daemons running natively under systemd. Question about "type=forking," though. The process that runs as the daemon is called by a script, or, more accurately, several scripts are called to actualy get it running. Isn't this the definition of a forked process? | |
| Aug 11, 2019 at 5:27 | history | answered | filbranden | CC BY-SA 4.0 |