3 ms·
"Run $X as user $Y, capture its output, restart it if it dies, and track its PID" for daemontools-style systems: #!/bin/bash cd /opt/minecraft-player ex
by dsr_ 4y ago
"Run $X as user $Y, capture its output, restart it if it dies, and track its PID" for daemontools-style systems:
#!/bin/bash
cd /opt/minecraft-player
exec 2>&1
exec setuidgid minecraft /usr/bin/java -Xmx2048M -Xms1024M -jar /opt/minecraft-player/server.jar --nogui --port 32122
and logging:
#!/bin/bash
exec multilog s10485760 n5 /var/log/minecraft-player
Logging is set for 10MB files, keep last 5.
The first one goes into a servicename/run file, and the second into servicename/log/run.
Running the run file is precisely what the daemontools system will do. There's no need to track the PID. `svstat servicename` will tell you how long it's been running or if it's disabled. The default is to restart on death, and if it flickers too much, disable it. Adding /etc/init.d wrappers to this is a 60 second edit of a skeleton file.
Code is superior to configuration when the code is this simple.
- dijit 4y agoAs much as I really really dislike systemd, bash is not the answer. I think we should try to do something better, I’m certain nobody will agree on a good language to use but I might propose starlark (a dialect of python, which recently got a rust implementation of the language thanks to Facebook). I should add: I’m quite adept at bash (I have the LinkedIn skill badge! (This is a joke)) but I can agree with people who dislike it, there are too many edge cases, it’s not easy to understand and while expressive and powerful: evidently we should have something that is easy too.
- dsr_ 4y agoFirst, there's no requirement to use bash. Any shell that has an exec equivalent and can redirect stderr to stdout will work. There's not even a requirement for it to be a script -- daemontools-style supervisors don't parse the run program, they execute it. It's pretty convenient to use the setuidgid tool, though. So if you want to run starlark, or oil, or your favorite lisp dialect, go ahead. In summation: bash isn't the problem here.
- dijit 4y agoThat's a really good point actually; Nothing prevents us using alternative interpreters for rc.d, ones with hooks for process supervision, hooks for something akin to cgroups, centralised logging and so on. But as a user who makes init scripts: you can do anything, which is pretty liberating when you really think about it.
- efortis 4y agoIn FreeBSD: /usr/sbin/daemon -R 2 \ # If terminated, restart after two seconds -u foouser \ -p /var/run/foo.pid \ -o /var/log/foo.error.log \ /usr/local/bin/foocmd https://github.com/uxtely/ops-utils/blob/main/location-server/jails/node_j/usr/local/etc/rc.d/node#L32 https://github.com/uxtely/ops-utils/blob/main/location-serve... https://www.freebsd.org/cgi/man.cgi?daemon(8) https://www.freebsd.org/cgi/man.cgi?daemon(8)
- Mister_Snuggles 4y agoFor some reason, I couldn't figure this out the last time I had to do it. This seems perfectly reasonable though.
- CoolCold 4y agoI'll take this thread as argument for _systemd_ as example simplified tooling for pretty standard tasks.