[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Handle-info] Starting and stopping the handle server from Unix rc scripts [SEC=UNCLASSIFIED]
Hi Robert,
Thank you for a very sensible and helpful response.
Several others have also pointed out that swing is not used in the
handle server, and there is no need for a frame buffer.
I am sure that nohup(1) would avoid most problems arising from sharing a
controlling terminal with other process, as SIGHUP is the signal you
would most often see -- when any process group leader did an exit(2).
However it's still very undesirable to expose a daemon to signals from
random other processes (which have the right to send any signal they
like to process group members).
I see that Tanuki is well regarded (the Apache foundation "endorse" it).
However I can't find documentation on *exactly* what it does, and it
also looks to be very heavy weight.
I will post my start/stop script solution as soon as I have tested it.
Cheers,
--
Phil
-----Original Message-----
From: Robert Tupelo-Schneck [mailto:schneck@cnri.reston.va.us]
Sent: Thursday, 29 July 2010 11:43 PM
To: Chadwick, Philip
Cc: handle-info@cnri.reston.va.us
Subject: Re: [Handle-info] Starting and stopping the handle server from
Unix rc scripts [SEC=UNCLASSIFIED]
If you consider your filesystem sufficiently secure, you do not need to
encrypt your server's private key, and that does make unattended startup
more straightforward.
In my experience, "nohup" has been entirely sufficient to prevent the
server dying in bizarre ways.
It sounds like you would be most satisfied, though, with a service
wrapper. Tanuki seems to be highly regarded and is known to work with
the handle server.
You will not need a frame buffer. Swing is only used for the graphical
client.
Best,
Robert
On 2010-07-28, at 19:28, Chadwick, Philip wrote:
> Hi Andy,
>
> Thank you. Also to Mike and Robert for helpful replies.
>
> I'm at a small disadvatage, since I don't actually run the handle
server
> yet.
>
> Also, I am no Java expert. I asked about Java Service Wrappers
because
> I have never used them and have more questions than answers at this
> time. I intend to investigate.
>
> My question related to the usual need for a daemon to detatch from the
> controlling terminal (/dev/console for rc start scripts), and become
> group leader of a new process group with a new session ID, all of
which,
> it seems, is beyond the normal scope of Java applications. You can't
> have a reliable daemon if you don't do these things!
>
> Section 2.5 of the Handle.Net Technical Manual (version 6.2) says
about
> starting the server:
>
> "Note: If you chose to encrypt your private key(s), you will be
> prompted for your passphrase here. Also note that Java (TM) does not
> have the ability to disconnect from a terminal so you will have to
> put the process in the background. On Unix systems type Ctrl Z, then
bg,
> then press ENTER."
>
> I must admit some deflation when I realised that the authors of the
> handle server expected it to have it's very own operator on call 24x7.
> It has not been daemonised. Nor are there recommendations in the
manual
> on how to do that. Sigh...
>
> For unattended booting, we won't be encrypting the (administrator's ?)
> private key, because we don't want the handle server to stall on
input,
> ever.
>
> I expect that the start/stop scrips posted leave the handle server
> attached to /dev/console as the controlling terminal after boot (or
what
> ever tty was last used to start the server). That means it will get
> signals directed at an inherited process group (rather than its own,
> private, process group). Very undesirable, and will cause the server
to
> die unexpectedly (usually from SIGHUP when somebody logs out) in
> aparently bizzare ways.
>
> A quick look at the handle server code shows it uses the swing
> libraries, which require a frame buffer display. I expect that the
> start/stop scrips posted are using the console hardware frame buffer.
I
> also expect that they would fail if there were no hardware frame
buffer.
>
> I think that the correct way to create the start/stop scripts is to
use
> a C program as wrapper [exactly the same as FreeBSD daemon(8)] to
> daemonise [see daemon(3) on Linux] before invoking the handle server
> with the DISPLAY pointed at a virtual frame buffer (Xvfb). The key
part
> of the start script would be:
>
> DISPLAY=":2.0"; export DISPLAY # you need to previously start
> "Xvfb :2"
> daemon -u handleuser $JAVA net.handle.server.Main /usr/local/hs/data
> 1>server.log 2>&1 &
>
> This is all theory. I don't know how the java interpreter will react
to
> being daemonised. When I get the handle server code running, I'll
port
> FreeBSD daemon(8) to Linux and run some trials.
>
> Cheers,
>
> --
> Phil
>
>
> -----Original Message-----
> From: Andy Stevens [mailto:stevens@electricalscience.com]
> Sent: Wednesday, 28 July 2010 11:47 PM
> To: Chadwick, Philip
> Subject: Re: [Handle-info] Starting and stopping the handle server
from
> Unix rc scripts [SEC=UNCLASSIFIED]
>
> Philip, attached is a start/stop script for the Handle server that
I've
> been using for many years on Red Hat Linux. It goes in /etc/init.d
and
> should be symlinked from the appropriate boot script dir.
>
> Regards,
>
> --Andy Stevens
>
>
> ------
> If you have received this transmission in error please notify us
immediately by return e-mail and delete all copies. If this e-mail or
any attachments have been sent to you in error, that error does not
constitute waiver of any confidentiality, privilege or copyright in
respect of information in the e-mail or attachments.
>
>
>
> Please consider the environment before printing this email.
>
> ------
>
>
> _______________________________________________
> Handle-Info mailing list
> Handle-Info@cnri.reston.va.us
> http://www.handle.net/mailman/listinfo/handle-info
>
------
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.
------
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info