>> my point is that having a child double forked does not mean Zookeeper TCP
>> port is ready which is as bad as simple which is also does not indicate
>> when it's ready
> Well, then Zookeeper is simply broken.
>> port is ready which is as bad as simple which is also does not indicate
>> when it's ready
> Well, then Zookeeper is simply broken.
sorry it's just me. I forget that the classic UNIX double fork do listen before the double fork not after it.
I'm sorry again it would be for sure ready when the inner child is forked if it was done the classical UNIX way (but it seems not, it's done by bash see below)
but anyway. let's discuss how it should be done properly.
> recommended way of launching Java-based applications as system services in systemd?
usually I love to pass -f to solr and I was considering passing "start-foreground" to make it foreground
because I don't have enough knowledge/trust in their bash scripts (and life is to short to read them and review them)
so I just short-circuit all background and process management and make systemd care about that.
this is "my way" not "the recommended way".
and of course I would love hear from people like you "the right way".
for example do they have a monitoring sub-process (to do auto restart)? how do they handle reload or restart ..etc?
if someone run the bash script directly telling it to restart what would happen ...etc.
all this is eliminated. I don't really care when solr is actually ready because my web application does not need solr to start (refresh page would work)
> Or should they all be launched by a shell script which implements the double-forking paradigm?
> is that just guessing or proven?
I used to believe that the double forking is done by java (after the socket is listening to requests) not bash.
but the bash script contains lines like this
nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &
if [ $? -eq 0 ]
...
/bin/echo -n $! > "$ZOOPIDFILE"
so I believe the forking is done by bash without a ready socket.
@Reindl.Harald the above bash is doing the fork, without any listening socket. so it's not guessing.
if you are like me don't really care about the exact time the socket is ready just foreground with type=simple
if you do care about that either in the part that need it use nc magic
for i in `seq 9`; do echo "" | nc localhost $PORT 1>/dev/null 2>/dev/null && echo "$PORT is up" && break; sleep 0.$i; done
you can wrap it in /bin/bash -c "...." if you need an absolute path.
> What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, gives the process a chance to actually signal when its' ready.
you can use "systemd-notify" in the bash script above just before "&& break"
but I would still go with foreground.
@Lennart Poettering is there a way to use something like "ExecStartPost=" do the the notify with type=simple?
On Mon, Jan 11, 2016 at 10:59 PM, Alec Leamas <leamas.alec@xxxxxxxxx> wrote:
On 11/01/16 21:19, Christopher wrote:
I'm a co-maintainer for ZooKeeper, and I'd like to help get this right,
if possible. More importantly, I'm interested in setting a precedent for
Java system services in systemd. So, forgive my ignorance, but what
exactly is the generally recommended way of launching Java-based
applications as system services in systemd? Is there a good model to
follow? A Java service that gets this right?
Also, as I understand it, Java processes don't really fork in any way
that's useful here. The JVM has it's own internal threading model. So,
what's the best way for them to play nice with systemd? Should they all
be simple? Or should they all be launched by a shell script which
implements the double-forking paradigm? If the latter, wouldn't that add
a lot of complication that systemd is designed to eliminate with the
simplicity of writing units?
What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, gives the process a chance to actually signal when its' ready.
Cheers!
--alec
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
