>> 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.
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.a...@gmail.com> 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@lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
>> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
