Hi Damien -
Apologies again for the delay in getting back to you. I tested the
--restart option with and without a delay from instantiation of the fwknop
deamon (without using the -f option and having bash place the job into the
background) . Under all circumstances, the daemon successfully restarted and
continued to run. Without the delay, results were mixed and would kill the
fwknop daemon more than half the time.
Thanks for the heads-up on the stderr redirect. I have been sending
stderr to the kernel messenger, which sysinit dumps to syslog after mounting
Linux localhost.localnet 18.104.22.168-56.fc13.x86_64 #1 SMP Wed Sep 15
03:36:55 UTC 2010 x86_64 GNU/Linux
On Fri, Sep 17, 2010 at 10:18 PM, Damien S. Stuart - dstuart@...
> Hi Will,
> In my testing, I found that running an fwknopd with --restart right after
> initially starting it would result in fwknopd shutting itself down. I would
> be interested in knowing if it would work (in your setup) if there was a
> short delay after the initial start of fwknopd (when started normally as a
> Regardless of how you decide to run it, please note that if fwknopd is run
> in the foreground, all logging goes to stderr instead of syslog. So if you
> want to retain the logging output when running in foreground mode, you will
> want to redirect stderr to a file...
> On 09/17/2010 10:03 AM, fwknopmail.20.miller_2555@... wrote:
> Hi Damien -
> Thanks - the immediate server restart is a bit of a misnomer. The
> fwknop server runs on a gateway for a small restricted network. Only certain
> teams are permitted to login during certain times, and I am using fwknop to
> limit access. I'm running a script to cycle access.conf for different time
> periods, so I restart the fwknop server periodically to load the new
> configuration. I'll try to test a bit more. In the interim, I've invoked the
> fwknop server to run in the foregroud, then use bash to place it into the
> background as a workaround:
> # - - Create script #1
> cat > ../script_1.sh << __EOF
> /sbin/fwknopd -f &
> chmod 0755../script_1.sh
> # - - Create script #2
> cat > ../script_2.sh << __EOF
> /sbin/fwknopd --restart
> chmod 0755../script_2.sh
> # - - Execute above scripts
> Thanks -
> On Thu, Sep 16, 2010 at 8:41 PM, Damien S. Stuart - dstuart@...
>> Hi Will,
>> 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, fwknopmail.20.miller_2555@... wrote:
>> Hello -
>> 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
>> chmod 0755../script_1.sh
>> # - - Create script #2
>> cat > ../script_2.sh << __EOF
>> /sbin/fwknopd --restart
>> chmod 0755../script_2.sh
>> # - - 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`.
>> Thanks -
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computinghttp://p.sf.net/sfu/novell-sfdev2dev
>> Fwknop-discuss mailing listFwknop-discuss@... href="nethttps://lists.sourceforge.net/lists/listinfo/fwknop-discuss" target="_new">nethttps://lists.sourceforge.net/lists/listinfo/fwknop-discuss