Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2006

Tip: Looking for answers? Try searching our database.

Java as Daemon in Linux

Thread view: 
dimitrik107@hotmail.com - 25 Aug 2006 15:11 GMT
I have java server process that I need to run as daemon in Linux 2.6.18

I need it to start when system boots up. I think I need to place the
start script in /etc/init/.

Can you share your script If you have done something like this?

I am using java 1.5.0_07 on Linux 2.6.18
Matt Rose - 25 Aug 2006 15:27 GMT
> I have java server process that I need to run as daemon in Linux 2.6.18
>
[quoted text clipped - 4 lines]
>
> I am using java 1.5.0_07 on Linux 2.6.18

It depends which distribution of linux you are using. Linux itself is
just the kernel at the heart of the system. The other ten thousand
programs installed when you install "linux" come from all sorts of
places (including gnu) and are collected together into a usable
operating system by the distribution provider (for example Debian or
Red Hat).

The method used for launching and controlling daemons varies from
distribution to distribution.

Matt
Jon Martin Solaas - 25 Aug 2006 17:01 GMT
>> I have java server process that I need to run as daemon in Linux 2.6.18
>>
[quoted text clipped - 16 lines]
>
> Matt

In /etc/rc.d/... there usually resides a bunch of other init scripts
that can be used as a starting point. Also search for "jboss init
script" or "tomcat init script" or something.

Most linux distros use Sys V style initscripts (slacware is an exception
I think). They don't differ much from distro to distro in functionality,
meaning they accept start, stop and restart parameter, but the actual
implementation may differ.
Martin Gregorie - 26 Aug 2006 12:08 GMT
>>> I have java server process that I need to run as daemon in Linux 2.6.18
>>>
> In /etc/rc.d/... there usually resides a bunch of other init scripts
> that can be used as a starting point. Also search for "jboss init
> script" or "tomcat init script" or something.

The scripts are all in /etc/rc.d/init.d. As a shortcut, some distros
(Fedora for one) provide a shortcut by also creating the hard link
/etc/init.d.

When you've copied a script and modified it to launch your server you
need to set up its run levels - usually you'll want it to run at levels
3 (network active), 4 (not usually used) and 5 (X-terminal active). You
set its run levels with the chkconfig command.

When the script is installed and working you can control it manually if
you login as root and use the service command (, e.g. "service myscript
status").

There's one thing to note: a server becomes a daemon when its parent has
exited. In C the server contains code something like:

    reply = fork();
    if (reply == 0)
    {
        /* If you got here you are the child process, so                  initialize the
server and carry out the its tasks
        */
    else
    {
        /* If you got here you are the forking process, which
          simply terminates so its child is a daemon
        */
        exit(0);
    }

This is needed if your launching script is to terminate: if you try to
start the server with "myserver &" your script will run to completion
but will then hang until all its children, i.e. your server, terminate
and this is NOT what you what. The C fragment above avoids that because
it duplicates the process containing it as a child and then terminates.
The result is that the child becomes a daemon (its parent is dead) and
the script will exit because all its children have terminated.

However, Java can't do the fork() trick (there's no fork() method in the
System class) but there is a shell script function that can do it for
you called "daemon". Pick on a script that uses it and modify that one.

The "crond" script looks like a good starting point.

> Most linux distros use Sys V style initscripts (slacware is an exception
> I think). They don't differ much from distro to distro in functionality,
>  meaning they accept start, stop and restart parameter, but the actual
> implementation may differ.

NOTE: starting your server this way is best for servers that are slow to
start and/or are almost constantly in use. If your server starts up fast
(i.e. in under a second) and is only rarely used, you might consider
starting it with the xinetd "super server". This way the server is
started when a client connects to it and it stops when the (last)
connection is closed. In practice the used can't tell whether a server
was started at boot time or via xinetd. For example sshd is usually
started at boot time but ftpd is normally started on demand by xinetd.

Signature

martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Jon Martin Solaas - 27 Aug 2006 19:34 GMT
> NOTE: starting your server this way is best for servers that are slow to
> start and/or are almost constantly in use. If your server starts up fast
[quoted text clipped - 4 lines]
> was started at boot time or via xinetd. For example sshd is usually
> started at boot time but ftpd is normally started on demand by xinetd.

Not sure if the JVM is suitable for this approach. It's fast as anything
once it's up and running, but it takes a while getting there... but it
all depends on load / request frequency and stuff. And maybe the java
code even is compiled to native executables... still it's kind of
similar to the old cgi wep-app interface...
Martin Gregorie - 27 Aug 2006 23:48 GMT
>> NOTE: starting your server this way is best for servers that are slow to
>> start and/or are almost constantly in use. If your server starts up fast
[quoted text clipped - 10 lines]
> code even is compiled to native executables... still it's kind of
> similar to the old cgi wep-app interface...

Agreed. I was in anal completist didactic mode when I wrote that.

Nothing I own would be fast enough to give an acceptable startup time,
but I only have a 766 MHz box with 256 MB RAM and little idea of how
fast a state of the art system might manage to start an
xinetd-controlled server.

Signature

martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Matt Rose - 29 Aug 2006 09:51 GMT
> >>> I have java server process that I need to run as daemon in Linux 2.6.18
> >>>
[quoted text clipped - 14 lines]
> you login as root and use the service command (, e.g. "service myscript
> status").

This is sound advice if you are on a Redhat derived system. The details
are slightly different on Debian derived systems. The run levels are
usually not used much: 1 means single user (i.e. for unusual
maintenance), 2 means normal. 3, 4 and 5 are not used by default,
although you're welcome to change this if you have a need. Also, the
scripts live in /etc/init.d. The /etc/rc.d symlink farm is maintained
using 'update-rc.d' instead of 'chkconfig' and services can be started
and stopped using 'invoke-rc.d' (or just by invoking the script
directly if you're just experimenting) instead of 'service'.

A good init script can cope with quite a few exceptional conditions,
many of which will vary according to the distro you are running on
(e.g. where should you store the pid file, where should you check for
java's existance and so on). I recommend you get hold of something like
tomcat packaged up for your particular system and have a look at the
init scripts that it comes with.

Matt


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.