If you are running these scripts one right after the other, it may be
the second script is sending the restart signal to the first one before
it has a chance to setup its signal handlers.
The primary reason for the --restart option is to tell a running fwknop
server to re-read its configuration and access.conf files, and flush
and reset the fwknop firewall rule set. When started with the
--restart option, fwknop simply determines the process ID of the
running fwknopd and sends a SIGHUP to it.
When the perl-based fwknopd was called with the --restart option, it
will completely kill the currently running fwknopd, then
start a new one.
May I ask why you are
starting the daemon, then sending a reconfig signal right away? I
cannot think of any reason this would be necessary.
If you really want to run the two scripts one after the other, you
should put a delay (i.e. "sleep 1") in between them. That should give
fwknopd sufficient time to get its signal handlers setup.
On 09/13/2010 11:25 AM, email@example.com wrote:
Does the fwknop server (v2.0.0rc1) fork off its parent when running
such that termination of the parent process does not terminate the
child process in which the fwknop server runs?
I have two `sh` scripts running consecutively in an initrd. The
first `sh` script kicks-off the fwknop daemon while the second performs
a restart of the daemon. Upon the restart directive, there are no
fwknop daemons found running. I had implemented the perl-based fwknop
server daemon using the aforementioned setup and the restart directive
in the second `sh` script was able to find and restart the fwknop
server daemon instantiated in the first `sh` script.
To recreate (simplified):
# - - Create script #1
cat > ../script_1.sh << __EOF
# - - Create script #2
cat > ../script_2.sh << __EOF
# - - Execute above scripts
To test, I amended the second `sh` script by: (i) inserting a debug
command to output `ps` into a file, followed by (ii) replacing the
restart directive with an invocation of a new fwknop daemon (using the
exact same directivesyntax as given in the first script) and (iii)
another debug command to output `ps` into a second file. I also
appended the `ps` debug command to the end of the first `sh` script to
ensure that it was successfully running. The test did snow successful
starts of the fwknop deamon in both instances. However, the fwknop
daemon terminates upon termination of the containing `sh`.
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
Fwknop-discuss mailing list