4 ms·
I tend to always use daemonize to start a Java program because typically I need to pass several startup options (like Xms, Xmx, etc.) and systemd unit files can
by quicksilver03 11y ago
I tend to always use daemonize to start a Java program because typically I need to pass several startup options (like Xms, Xmx, etc.) and systemd unit files cannot perform even the simplest variable interpolation needed [1].
Someday systemd will go beyond simple key-value substitution, and on that day I'll stop using daemonize.
[1]: http://www.opsfordevelopers.com/2015/05/startup-scripts-for-java-based-services/ http://www.opsfordevelopers.com/2015/05/startup-scripts-for-...
- hactually 11y agoWhat's wrong with doing something like the following: ... [Service] Type=forking EnvironmentFile=-/usr/local/myJavaConfig ExecStart=/bin/sh -c '${JAVA_HOME} ${JAVA_OPTS}' Or if you're after passing things in, use the other technique that lets you use systemctl myservice@your_sub.service
- JdeBP 11y agoTwo things are wrong, neither of which, however, make daemonize appropriate. First, and trivially, there's a missing /bin/java (-: Second, that's a potential readiness protocol and a main PID mismatch. See http://unix.stackexchange.com/a/200365/5132 http://unix.stackexchange.com/a/200365/5132 for details. And then http://askubuntu.com/a/624871/43344 http://askubuntu.com/a/624871/43344 . Remembering to exec is another lesson to bring along from the daemontools world.
- yrro 11y agoThat's a case for creating a wrapper shell script that you launch through ExecStart=. Nothing to do with whether your process does the daemon(7) dance or not.
- quicksilver03 11y agoCorrect, I should've been clearer that I use daemonize mostly out of frustration with systemd limitations and inability to tell me precisely what's wrong when there are errors launching the service.