Hello Andredoles,
all that nohup does is disable SIGHUP for its children. If those
re-enable this signal, or if your sshd sends another signal as well
(e.g. SIGINT/SIGTERM) to the process group that defines your login
session, then your process would die. Just for experiments sake you
may want to start your application in the background, and then run
nohup -p -Fa <pid> to see what happens when you log out afterwards.
You may also want to run 'truss -t\!all -sall -Sall -f java
Chat.Server >& log &' and see what the last few lines in the log look
like when you subsequently exit the shell. The log file should record
what kind of signal the java process did receive. I could not test
this myself, since my java processes stick around when I log out...
Now, those two steps may help you find out what is going on, but maybe
wont lead to a cure. As a quick and dirty solution I would suggest
that you use a little wrapper program to launch your application. This
is not pretty or anything, but it beats booting the box any day.
Here a suggestion for such a wrapper. Please note that this is *not*
secure code, the use of system() would allow a hacker to wreak
mischief with environment variables and such. So don't let this
program be setuid root (chmod 4755). There are surely many ways to
demonize a process, this is just one. In the system() library call,
just change the argument to 'java Chat.Server', or
use execvp.
I hope this resolves your problem, if not please do not hesitate to
get back to me with a clarification request, and I will see what I can
do.
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <stropts.h>
#include <fcntl.h>
#include <termio.h>
#include <sys/stat.h>
#include <sys/types.h>
int main(int argc, char *argv[])
{
int pid;
int devttyfd;
if ((pid = fork()) < 0) {
perror("daemonize(): fork failed\n");
_exit(0);
}
/* are we the child? */
if (pid > 0) { /* no */
_exit(0);
}
/* Disassociate from the process group */
(void) setpgrp();
/* Redirect stdio to/from the null device. */
freopen("/dev/null", "r", stdin);
freopen("/dev/null", "w", stdout); /* point this to logfile if
desired */
freopen("/dev/null", "w", stderr); /* point this to logfile if
desired */
if ((devttyfd = open("/dev/tty", O_WRONLY)) < 0) {
/* open failed: we don't have to detach ourselves. */
;
} else {
(void) ioctl(devttyfd, TIOCNOTTY, (char *) 0);
(void) close(devttyfd);
}
/* instead of system, use execvp(), to get rid of the extra
process! */
/* just provide the command and arguments on the command line ...
*/
/* e.g. wrapper touch /tmp/file */
/* execvp(argv[1], &(argv[1])); */
system("date | tee /tmp/date.log");
return 0;
}
Friendly greetings,
Philp Lynx
p.s. as a crazy quick solution, you may also want to try to run it
with the
'at' command:
at now
java ...
^D
:-) |
Request for Answer Clarification by
andredoles-ga
on
10 Jul 2003 11:39 PDT
We tried your recommendation, but it didn't quite work. We spent all
day yesterday on it, and although your information is what lead us to
understand/debug it to be a java bug, noted in document
http://developer.java.sun.com/developer/bugParade/bugs/4755829.html,
it still doesn't work for us... but it's not a nohup issue anymore.
Thanks for your help. You've provided us with the answer to help us
resolve what the actual problem really was. Sometimes, that's not so
obvious.
For others with similar issues, here is the snippet we found that
explains the problem we encountered:
snip
----------
The later release of JVM 1.3.1-04 to JVM 1.3.1-05 are ignoring the
nohup(1)
command. Instead of ignoring the SIGHUP, it actually caught and
process the
SIGHUP signal, resulting in the java application being exited with a
return
code of 129.
nohup(1) command is working correctly on the following releases:
JVM 1.3.1-FCS - OK
JVM 1.3.1-01 - OK
JVM 1.3.1-02 - OK
JVM 1.3.1-03 - OK
nohup(1) command is NOT working on the following releases:
JVM 1.3.1-04 - NOT OK (not ignored)
JVM 1.3.1-05pre - NOT OK (not ignored)
The above findings are reproducable.
------------
/unsnip
However, even now that we can nohup it, the app still won't run but we
believe it's because of an X11 problem. We are using the java option
"-Djava.awt.headless=true", but we still can't get it to work, but at
least it does stay alive... it just doesn't work though.
|
Clarification of Answer by
philip_lynx-ga
on
11 Jul 2003 03:09 PDT
Dear Andredoles,
well, I am glad my answer was not completely useless. So with the new
solution, the process does not run at all? Or is just the fact that it
dies when you log out? As per your snippet, the previous on-logout
issue appears to be exactly the reenabling of SIGHUP, as describend in
the second line of my answer.
Also, may I just for curiosities sake and to make future answers more
satisfying enquire as to what more you would have expected from me to
'reward' me with a 5-star rating, given the price cap on your
question?
|
Request for Answer Clarification by
andredoles-ga
on
11 Jul 2003 12:16 PDT
Nothing. I thought about it directly after I posed it. I wanted to
go back and change it to 5, because you did everything you could with
the information provided, to help me. My original thought of why I
put 4 was because it didn't totally solve my problem. We were close,
but no cigar. Then, in thinking about it, it was attributed to a
"bug" in java, which is not your fault, nor related to the original
question. So, while I wanted to upgrade it to a 5, I have no way of
doing so. Is there an email address I can write to, to request it be
upgraded. Sorry for dinging your rating. I just wasn't thinking in
those terms...
|
Clarification of Answer by
philip_lynx-ga
on
23 Jul 2003 02:56 PDT
Thank you very much for your consideration in fixing the rating up.
However, google editors say:
] We are sorry, because there is no way to change a customer rating
once
] it has been given. Although this does present inconveniences when a
] customer wants to raise a rating, it also prevents customers from
] arbitrarily lowering ratings too.
A sword that cuts both ways, it seems. So, never mind, and I hope you
will find Google answers useful in the future as well :-)
|
