SEO

Hello,

I'm currently installing two java programs to run as a service under
debian/woody.

I'm familiar with the basic concepts of start scripts under linux. I
know about the runlevels and the init.d and rcX.d directories.

I finally managed to install the two java start scripts in such a way
that the java programs would actually stay up runnning.

But for this I had to use the "su" and "nohup" command. And now I'm
curious about why I have to use these.

If somebody could elaborate a little bit on this and linux services in
general I would really appreciate it.

I still don't really understand, why my java program would not stay
alive, when I merely entered the following line into the linux start
script:

cd /opt/mp/bin
java -jar myprogram.jar &

Like this the program would not stay up running, even though I could
start the program by running the linux start script from a remote
console.

I then read that supposedly the problem is that after the linux start
script stops all its child processes die and therefore also the java
command.

Is that true?

However, it's true that merely this line would not make my program
start at boot time. I had to use the "nohup" and "su" command. This
worked.

The problem I'm left with now, is that I actually have no controll
over the timing and sequence in which my programs get executed.

The problem is that the second program needs the first one. So if the
first one takes too long to start up, the secons one raises an error.

I solved this by starting the first program at the very beginning and
the second one at the very very end (S01 and S99).

However, now I'm actually depending on a race condition. I do not feel
very comfortable with this solution.

I would like to know how I can assure that my program actually runs
after the script finishes? How do I manage dependencies. And why does
a simple "java myprogram &" not work and need a "nohub" or "su" ??

Fritz

fritz-bayer@web.de (Fritz Bayer) wrote in
news:a9c0aa9e.0411071443.2c6ccf8f@posting.google.c om:

> Hello,
>
> I'm currently installing two java programs to run as a service under
> debian/woody.
>
> I'm familiar with the basic concepts of start scripts under linux. I
> know about the runlevels and the init.d and rcX.d directories.
>
> I finally managed to install the two java start scripts in such a way
> that the java programs would actually stay up runnning.
>
> But for this I had to use the "su" and "nohup" command. And now I'm
> curious about why I have to use these.
>
> If somebody could elaborate a little bit on this and linux services in
> general I would really appreciate it.
>
> I still don't really understand, why my java program would not stay
> alive, when I merely entered the following line into the linux start
> script:
>
> cd /opt/mp/bin
> java -jar myprogram.jar &
>
> Like this the program would not stay up running, even though I could
> start the program by running the linux start script from a remote
> console.
>
> I then read that supposedly the problem is that after the linux start
> script stops all its child processes die and therefore also the java
> command.
>
> Is that true?
>
> However, it's true that merely this line would not make my program
> start at boot time. I had to use the "nohup" and "su" command. This
> worked.
>
> The problem I'm left with now, is that I actually have no controll
> over the timing and sequence in which my programs get executed.
>
> The problem is that the second program needs the first one. So if the
> first one takes too long to start up, the secons one raises an error.
>
> I solved this by starting the first program at the very beginning and
> the second one at the very very end (S01 and S99).
>
> However, now I'm actually depending on a race condition. I do not feel
> very comfortable with this solution.
>
> I would like to know how I can assure that my program actually runs
> after the script finishes? How do I manage dependencies. And why does
> a simple "java myprogram &" not work and need a "nohub" or "su" ??
>
> Fritz
>

I hope the following might works for you or some variation on the theme.
In your first script do some thing ( create a file, open a socket & send a
message, etc) at the very end when it is really ready to run. In the second
script have it start, but wait for the flag from the 1st script before
proceeding with its actual startup code.

Some how I doubt the "su" is really required.

FWIW - the line "java myprogram &" has the java process running "in the
backkground"; BUT it still depend upon its parent process to stay alive.
This is because the background process is a child process of its parent;
the process from which "java myprogram &" was issued. When the parent
process dies the child process gets terminated.

The "nohup" (no hangup) instructs the OS to allow the process to stay alive
after the parent process terminates.

In article <Xns959AA26D0EEF5SunnySD@68.6.19.6>,
"IANAL_VISTA" <IANAL_Vista@hotmail.com> wrote:

>Some how I doubt the "su" is really required.
>
>FWIW - the line "java myprogram &" has the java process running "in the
>backkground"; BUT it still depend upon its parent process to stay alive.
>This is because the background process is a child process of its parent;
>the process from which "java myprogram &" was issued. When the parent
>process dies the child process gets terminated.
>
>The "nohup" (no hangup) instructs the OS to allow the process to stay alive
>after the parent process terminates.

Let me just add to this that most of the programs being run from init.d
scripts make their own provisions for running detached from the
invoker's terminal and process group, by using the fork(2) and setsid(2)
system calls.

If the original poster has access to the Java source code, it could
probably be modified to do the same.

Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> wrote in message news:<ldo-40556C.19594808112004@lust.ihug.co.nz>...
> In article <Xns959AA26D0EEF5SunnySD@68.6.19.6>,
> "IANAL_VISTA" <IANAL_Vista@hotmail.com> wrote:
>
> >Some how I doubt the "su" is really required.
> >
> >FWIW - the line "java myprogram &" has the java process running "in the
> >backkground"; BUT it still depend upon its parent process to stay alive.
> >This is because the background process is a child process of its parent;
> >the process from which "java myprogram &" was issued. When the parent
> >process dies the child process gets terminated.
> >
> >The "nohup" (no hangup) instructs the OS to allow the process to stay alive
> >after the parent process terminates.
>
> Let me just add to this that most of the programs being run from init.d
> scripts make their own provisions for running detached from the
> invoker's terminal and process group, by using the fork(2) and setsid(2)
> system calls.
>
> If the original poster has access to the Java source code, it could
> probably be modified to do the same.

Thank you two for the replies. So I understand that the first problem
really arises from the parent child relationship.

Thanks to the second posting, I also understand now, why it's a
problem for my java program in particular and why most start scripts
in init.d using a & keep on running.

However, I'm not sure if it's possible to use a fork or something
alike in Java. I doubt it since java is os independent.

Anyway I was wondering whether or not their exists another solution to
my concurrency problem with the two start scripts.

Ok I could run a loop until the first one has started. But isn't it
possible to wait somehow until the program has started up...

Fritz Bayer <fritz-bayer@web.de> wrote:
> Lawrence D?Oliveiro <ldo@geek-central.gen.new_zealand> wrote in message news:<ldo-40556C.19594808112004@lust.ihug.co.nz>...
> > In article <Xns959AA26D0EEF5SunnySD@68.6.19.6>,
> > "IANAL_VISTA" <IANAL_Vista@hotmail.com> wrote:
> >
> > >Some how I doubt the "su" is really required.
> > >
> > >FWIW - the line "java myprogram &" has the java process running "in the
> > >backkground"; BUT it still depend upon its parent process to stay alive.
> > >This is because the background process is a child process of its parent;
> > >the process from which "java myprogram &" was issued. When the parent
> > >process dies the child process gets terminated.

No it doesn't! This is a particular "feature" of one shell - bash, and
it is modified by the option huponexit.

The shell exits by default upon receipt of a SIGHUP. Before exiting,
it resends the SIGHUP to all jobs, running or stopped. Stopped jobs
are sent SIGCONT to ensure that they receive the SIGHUP. To prevent
the shell from send* ing the signal to a particular job, it should be
removed from the jobs table with the disown builtin (see SHELL
BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown
-h.

If the huponexit shell option has been set with shopt, bash sends a
SIGHUP to all jobs when an interactive login shell exits.

You can unset the bash option (or simply not set it), use disown, nohup,
whatever. In general, processes do NOT die when their parent dies!
That would be crazy.

> > >The "nohup" (no hangup) instructs the OS to allow the process to stay alive
> > >after the parent process terminates.
> >
> > Let me just add to this that most of the programs being run from init.d
> > scripts make their own provisions for running detached from the
> > invoker's terminal and process group, by using the fork(2) and setsid(2)
> > system calls.

Well, that is, in their own code, they "go daemon" in the standard
way. Fork, cd /, close all descriptors, fork again.


> > If the original poster has access to the Java source code, it could
> > probably be modified to do the same.

Not necessary. Java will launch daemon processes! The java thread library
has special calls/options to do so.

> Thank you two for the replies. So I understand that the first problem
> really arises from the parent child relationship.

What forst problem? And no, you do not so understand, because there is
no implication that parent/child will cause the child to die when the
parent does! That's crazy. There is a special setting in the bash
shell that will enable that, but it is not normal.

> Thanks to the second posting, I also understand now, why it's a
> problem for my java program in particular and why most start scripts
> in init.d using a & keep on running.

Well, that's nothing really to do with it - they may be started with &
but that's only a habit of the programmer. Honest daemons will go
daemon by themselves however you start them, with & or without.


> However, I'm not sure if it's possible to use a fork or something
> alike in Java. I doubt it since java is os independent.

Nonsense. Java's process/thread methods cater specifically for all
this! Java is a parallel processing language.

> Anyway I was wondering whether or not their exists another solution to
> my concurrency problem with the two start scripts.

What "concurrency problem"? It really sounds like you want to read a
book on java threads.

> Ok I could run a loop until the first one has started. But isn't it
> possible to wait somehow until the program has started up...

Of course. That's normal. "Wait" on the other.

Peter

On 7 Nov 2004 14:43:38 -0800, Fritz Bayer
<fritz-bayer@web.de> wrote:
> Hello,
>
> I'm currently installing two java programs to run as a service under
> debian/woody.
>
> I'm familiar with the basic concepts of start scripts under linux. I
> know about the runlevels and the init.d and rcX.d directories.
>
> I finally managed to install the two java start scripts in such a way
> that the java programs would actually stay up runnning.
>
> But for this I had to use the "su" and "nohup" command. And now I'm
> curious about why I have to use these.
>
"su" shouldn't be absolutely necessary, but for security reasons it
might be good if you can run your script as a user other than root.


--
"How can 59,054,087 people be so dumb?" And that's the headline in
Britain, our closest ally. But here in America, as long as you-know-who
is president, we don't give a $%&# what the rest of the world thinks.

First: Doesn't debian have some utility designed for this, like the
start-stop-daemon program?

Peter T. Breuer wrote:
> No it doesn't! This is a particular "feature" of one shell - bash, and
> it is modified by the option huponexit.
>
> The shell exits by default upon receipt of a SIGHUP. Before exiting,
> it resends the SIGHUP to all jobs, running or stopped. Stopped jobs
> are sent SIGCONT to ensure that they receive the SIGHUP. To prevent
> the shell from send* ing the signal to a particular job, it should be
> removed from the jobs table with the disown builtin (see SHELL
> BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown
> -h.
>
> If the huponexit shell option has been set with shopt, bash sends a
> SIGHUP to all jobs when an interactive login shell exits.
>
> You can unset the bash option (or simply not set it), use disown, nohup,
> whatever. In general, processes do NOT die when their parent dies!
> That would be crazy.

Okay, good point... But not entirely true, it seems:

27.5 Orphaned Process Groups
============================

When a controlling process terminates, its terminal becomes free and a
new session can be established on it. (In fact, another user could log
in on the terminal.) This could cause a problem if any processes from
the old session are still trying to use that terminal.

To prevent problems, process groups that continue running even after
the session leader has terminated are marked as "orphaned process
groups".

When a process group becomes an orphan, its processes are sent a
`SIGHUP' signal. Ordinarily, this causes the processes to terminate.
However, if a program ignores this signal or establishes a handler for
it (*note Signal Handling:, it can continue running as in the orphan
process group even after its controlling process terminates; but it
still cannot access the terminal any more.


libc info 0.10.



>> > If the original poster has access to the Java source code, it could
>> > probably be modified to do the same.
>
> Not necessary. Java will launch daemon processes! The java thread library
> has special calls/options to do so.

I hope you're not thinking of setDaemon(). It seems that its purpose is to
designate threads that are to die if there are no longer any "user"
threads, contrary to extending their lifespans. A java server might be an
exception to this, but haven't tested with one.

> What forst problem? And no, you do not so understand, because there is
> no implication that parent/child will cause the child to die when the
> parent does! That's crazy. There is a special setting in the bash
> shell that will enable that, but it is not normal.

Define normal? Using SIGHUP is a security feature.

>> However, I'm not sure if it's possible to use a fork or something
>> alike in Java. I doubt it since java is os independent.
>
> Nonsense. Java's process/thread methods cater specifically for all
> this! Java is a parallel processing language.

Yes, study that threading architecture!

>> Anyway I was wondering whether or not their exists another solution to
>> my concurrency problem with the two start scripts.
>
> What "concurrency problem"? It really sounds like you want to read a
> book on java threads.

Not if there is a desire for two distinct programs, even wherewithal
dependencies. However, I can't see why the second (dependent) program
can't run the first.

Speaking of OS independent, there exists a native code interface, by which
you can write C/etc., system code and use it in java.

>> Ok I could run a loop until the first one has started. But isn't it
>> possible to wait somehow until the program has started up...

Waiting implies some kind of loop, possibly obscured at the kernel level.

> Of course. That's normal. "Wait" on the other.

Almost funny (Object.wait()), but not quite. Can't you be a little nicer?

Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

Jon Gomez <jon.gomez.04@cnu.edu> wrote:
> > You can unset the bash option (or simply not set it), use disown, nohup,
> > whatever. In general, processes do NOT die when their parent dies!
> > That would be crazy.
>
> Okay, good point... But not entirely true, it seems:
>
> 27.5 Orphaned Process Groups
> ============================

Where is this from?

> When a controlling process terminates, its terminal becomes free and a
> new session can be established on it. (In fact, another user could log
> in on the terminal.) This could cause a problem if any processes from
> the old session are still trying to use that terminal.
>
> To prevent problems, process groups that continue running even after
> the session leader has terminated are marked as "orphaned process
> groups".

Just test. You'll find that processes launched from a shell are NOT
sent a HUP when their parent dies, if huponexitwhatever is not set.
I hope! So what you say cannot be true in that case.

> When a process group becomes an orphan, its processes are sent a
> `SIGHUP' signal. Ordinarily, this causes the processes to terminate.
> However, if a program ignores this signal or establishes a handler for
> it (*note Signal Handling:, it can continue running as in the orphan
> process group even after its controlling process terminates; but it
> still cannot access the terminal any more.
>
>
> libc info 0.10.

Oh - I must say I have never had an info file for libc! But anyway, you
can see the problem: libc is not emotionally involved. When a process
dies it dies, independently of whether it is compiled against libc or
not!

>
> >> > If the original poster has access to the Java source code, it could
> >> > probably be modified to do the same.
> >
> > Not necessary. Java will launch daemon processes! The java thread library
> > has special calls/options to do so.
>
> I hope you're not thinking of setDaemon().


As far as I recall I am. But I haven't looked for several years.

> It seems that its purpose is to
> designate threads that are to die if there are no longer any "user"
> threads,

You can designate user and daemon threads. Daemon threads are intended
to not be subject to certain restrictions. I believe you have misread.


> contrary to extending their lifespans. A java server might be an
> exception to this, but haven't tested with one.

??? This is ordinary java.

> > What first problem? And no, you do not so understand, because there is
> > no implication that parent/child will cause the child to die when the
> > parent does! That's crazy. There is a special setting in the bash
> > shell that will enable that, but it is not normal.
>
> Define normal? Using SIGHUP is a security feature.

Test and see.

> >> However, I'm not sure if it's possible to use a fork or something
> >> alike in Java. I doubt it since java is os independent.
> >
> > Nonsense. Java's process/thread methods cater specifically for all
> > this! Java is a parallel processing language.
>
> Yes, study that threading architecture!

??? Java has threads. In a "green thread" implementation of java, they
will be emulated in the support architecture. In a "native thread"
implementation, they will be translated to arch threads. The latter
are processes on linux.

> > What "concurrency problem"? It really sounds like you want to read a
> > book on java threads.
>
> Not if there is a desire for two distinct programs, even wherewithal

Especially if so. Java is a parallel language. See the threads class.

> dependencies. However, I can't see why the second (dependent) program
> can't run the first.

????


> Speaking of OS independent, there exists a native code interface, by which
> you can write C/etc., system code and use it in java.

Sure - why not. But it's silly. You can compile java.

> >> Ok I could run a loop until the first one has started. But isn't it
> >> possible to wait somehow until the program has started up...
>
> Waiting implies some kind of loop, possibly obscured at the kernel level.
>
> > Of course. That's normal. "Wait" on the other.
>
> Almost funny (Object.wait()), but not quite. Can't you be a little nicer?

??? Yes, as I recall, wait() is a method of the object class. What are
you trying to say?

Peter

Peter,

It looks like I should try to write more clearly. :-( Maybe I can do
better this time. (except I'm writing it in the middle of night, very
tired, so forgive sp/grammar errors)


Peter T. Breuer wrote:


> Just test. You'll find that processes launched from a shell are NOT
> sent a HUP when their parent dies, if huponexitwhatever is not set.
> I hope! So what you say cannot be true in that case.

I'm sure it's true. My question is how the shell interacts with the way
other parts of the system (kernel, system libraries = libc). My research
suggests that the shell's setting immunity to SIGHUP is part of a larger
context. I will do more studying (give me a few days), and get back to
you. If you want, you can look up the gnu libc manual online (easily
googled), and find what I was quoting under "Job Control".

Looking some more does state that in the general case a process is assigned
a new parent on parent death (usu. init)... but I think terminals are
different. I will have to find out.

> When a process
> dies it dies, independently of whether it is compiled against libc or
> not!

True.

>> It seems that its purpose is to
>> designate threads that are to die if there are no longer any "user"
>> threads,
>
> You can designate user and daemon threads. Daemon threads are intended
> to not be subject to certain restrictions. I believe you have misread.

Not only did I read it in the 1.4 sdk api and look up an alternative
reference, but I ran a sample program. Here is an improved version (set
RunAsDaemon true for daemon, false for normal thread.) The thread sends
output to a file it creates in /tmp/daemon-test continuously, so you should
be able to tail -f it:

import java.io.*;

public class daemon implements Runnable {
static boolean RunAsDaemon = false;


String fname = "/tmp/daemon-test";
String text = "teststuff\n";
FileWriter f;


//Starts up a new daemon
public static void main(String args[]) {
Thread t;
daemon d;

System.out.println("Starting new thread");
d = new daemon();
t = new Thread(d);

// Make that sucker a daemon thread!
if(RunAsDaemon) {
try {

t.setDaemon(true);
} catch (SecurityException se) {
System.out.println("Not allowed!");
} catch (IllegalThreadStateException itse) {
System.out.println("Hm... shouldn't happen ;-)");
}
}
t.start();

System.out.println("main() finished");
}

// Open a file for writing and write to it continuously
// we can use 'tail -f' to watch if anything is happening.
public void run() {
System.out.println("Thread has started.");

try {
f = new FileWriter(fname);
} catch(IOException ie) {
System.out.println("File can't be opened!");
}


while(true) {
try {
f.write(text);
f.flush();
Thread.sleep(1000);
} catch(InterruptedException ie) {
} catch(IOException ie) {
System.out.println("Error writing to file");
}
}


} //end of run()

} //end of class daemon


>> A java server might be an
>> exception to this, but haven't tested with one.
>
> ??? This is ordinary java.

There are versions of java that run as background system processes, for
example, on the Solaris computers at my school, and serve requests for
running java applications, rather than starting a new vm each time. Please
see the following reference:
http://java.sun.com/j2se/1.4.2/docs/guide/vm/index.html


>> Define normal? Using SIGHUP is a security feature.
>
> Test and see.

What I mean is, the goal of SIGHUP is to heap ensure that the terminal is
clean of dubious processes, isn't it?


>> Yes, study that threading architecture!
>
> ??? Java has threads. In a "green thread" implementation of java, they
> will be emulated in the support architecture. In a "native thread"
> implementation, they will be translated to arch threads. The latter
> are processes on linux.

I was agreeing with you. You're straight on.


>> > What "concurrency problem"? It really sounds like you want to read a
>> > book on java threads.
>>
>> Not if there is a desire for two distinct programs, even wherewithal
>
> Especially if so. Java is a parallel language. See the threads class.

Could be. I think creating separate programs goes beyond the idea of
separate processes, insofar as it could be a case where the first program
is highly self-defined but the second not so. I mean, we could design our
software in a way that is monolithic to the user, but I prefer applications
broken into pieces. So the question is for our friend to decide, because
he is the one writing the program(s). But I agree, considering that they
are init-scripts, and for limited use only, they probably would do better
as threads.


>> Speaking of OS independent, there exists a native code interface, by
>> which you can write C/etc., system code and use it in java.
>
> Sure - why not. But it's silly. You can compile java.

You're right it's silly. And fun. Heck, one day I want to write java in
bytecode. I've already practiced reading the class files in hex a little.
There's apparently a programming tool called SWIG which eases the task of
connecting all sorts of languages.


>> Almost funny (Object.wait()), but not quite. Can't you be a little
>> nicer?
>
> ??? Yes, as I recall, wait() is a method of the object class. What are
> you trying to say?

I apologize- I made an inappropriate assumption here. I thought you were
making fun of Fritz. To be honest, I worried about this after I sent my
message off.


Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

Jon Gomez <jon.gomez.04@cnu.edu> wrote:
> Peter T. Breuer wrote:
> > Just test. You'll find that processes launched from a shell are NOT
> > sent a HUP when their parent dies, if huponexitwhatever is not set.
> > I hope! So what you say cannot be true in that case.
>
> I'm sure it's true.

Then become a bit more unsure and simply test.

> My question is how the shell interacts with the way
> other parts of the system (kernel, system libraries = libc).

It doesn't - the shell is written in C and compiled against libc, so it
partakes of whatever properties the routines in libc have. That's all.

> My research
> suggests that the shell's setting immunity to SIGHUP is part of a larger
> context.

The only mechanism possible would be to set the daughter shells to a
different session or to set them to ignore sighup, but the latter would
be imposible as they must be able to trap it at will. So you will get
to test whether they are in the same session group or not - that's a
question of stracing them. It doesn't take forever to do, just a few
seconds or minutes.

> I will do more studying (give me a few days), and get back to

Just testing is required - really! Tell me the results! I would like to
know what you see.

> you. If you want, you can look up the gnu libc manual online (easily
> googled), and find what I was quoting under "Job Control".


> Looking some more does state that in the general case a process is assigned
> a new parent on parent death (usu. init)... but I think terminals are

Again, that's really none of libc's business. The kernel reassigns the
process to init. It just fills the number 1 into the process struct slot
for ppid.

> different. I will have to find out.

A process is still a process. The question is whether the kernel sends
them sighup or not when the session group is orphaned by the death of
the leader. That can be tested.

> > You can designate user and daemon threads. Daemon threads are intended
> > to not be subject to certain restrictions. I believe you have misread.
>
> Not only did I read it in the 1.4 sdk api and look up an alternative
> reference, but I ran a sample program. Here is an improved version (set

That's OK. Daemon threads are indeed cleaned up by the interpreter as
soon as the last user thread has ended, but their intended use is still
for "non-interactive stuff", i.e. daemons. But their persistence is
indeed not longer than that of the virtual machine they are in, which
will die when the last user thread dies.

So make sure that you have one user thread in the virtual machine if
you want the daemons to stick around. But why not ue the user thread
to do the wor you want the daemon to do, as it makes not much
difference.

Anyway, you are right - the daemon flag in java is not used to help one
"go daemon" in the unix sense.

> >> A java server might be an
> >> exception to this, but haven't tested with one.
> >
> > ??? This is ordinary java.
>
> There are versions of java that run as background system processes, for

That makes no difference.

> > Test and see.
>
> What I mean is, the goal of SIGHUP is to heap ensure that the terminal is
> clean of dubious processes, isn't it?

I don't see why. One usually WANTS to leave the processes one started
running, running, when one logs out. X sessions tend to kill xterms
because the X server dies and o they have nothing to live on, not for
any more profound reason. But terminal sessions shouldn't normally kill
the processses you left running in the background. It never used to be
historically the case in any unix I can remember, by default.

> > Especially if so. Java is a parallel language. See the threads class.
>
> Could be. I think creating separate programs goes beyond the idea of
> separate processes, insofar as it could be a case where the first program
> is highly self-defined but the second not so. I mean, we could design our
> software in a way that is monolithic to the user, but I prefer applications
> broken into pieces. So the question is for our friend to decide, because
> he is the one writing the program(s). But I agree, considering that they
> are init-scripts, and for limited use only, they probably would do better
> as threads.
>

Not sure what you mean here, but good luck!

Peter