pid files...

Fri Jul 15 10:33:14 EDT 2011

Hey Phillip,
Regarding pid files for ra* programs.  Any ra* program can set a pid file
using the rarc configuration.  Here is the blurb from the rarc sample configuration
in ./support/Config/rarc:

# Any ra* program can generate a pid file, which can be
# used to control the number of instances that the system
# can support.  However, creating a system pid file may
# require priviledges that are inappropriate for all cases.
#
# When configured to generate a pid file, if a file called
# ra*.pid (where ra* is the name of the program in question)
# exists in the RA_PID_PATH directory, and a program
# exists with a pid that matches the one contained in the
# file, then the program will not start.  If the pid does
# not exist, then the ra* program replaces the value in the
# file, with its own pid.   If a pid file does not exist,
# then the ra* program will create it in the RA_PID_PATH
# directory, if it can.  The end result is that the system
# will support only one instanace of the program, based
# on name, running at a time.
#
# The default value is to not generate a pid.  The default
# path for the pid file, is /var/run.
#
# No Commandline equivalent
#
#
RA_SET_PID="no"
RA_PID_PATH="/var/run"

Not sure why this isn't in the rarc man page, but it is now.
Please give this a run, to see if will do what you want.

Carter

On Jun 29, 2011, at 9:04 AM, Phillip Deneault wrote:

> I can't speak for Russell, but I've run into the same race condition of
> defining pids for multiple Argi.
> 
> I define one Argus service per interface and then use the pid to track
> whether I am no longer monitoring that interface using Monit.  This has
> been extremely useful in finding Argi who have otherwise crashed across
> my various sensors to keep my monitoring posture as consistent as
> possible.  Using a single Argus instance to monitor both interfaces
> would not be ideal in this situation since I would have no idea which
> interface stopped monitoring or for how long.
> 
> In my configuration, the naming convention which keeps the interface
> name works fine, but if you want to support multiple interfaces per Argi
> as well as multiple Argi per interface, it may be best to just allow the
> definition of an arbitrary PID name and path for each Argi.
> Unless, I've interpreted your messages totally wrong.
> 
> Not to get off the subject, but there are other places where being able
> to define a pid would be useful in some of the client tools.  Radium and
> rastream jump into my head since they can be used as long-running
> processes that have the potential to hiccup at certain intervals and
> would need to be restarted.  Maybe whatever gets worked out could be
> added to those clients as well as an optional variable?  I'm monitoring
> these services now, but I wrap these processes with python scripts which
> generate the pids, and it works, but its pretty gross.
> 
> Thanks,
> Phil
> 
> On 6/28/2011 10:11 PM, Carter Bullard wrote:
>> Hey Russell, I looked at pid file processing and found a bug, which I
>> have fixed, but I'm perplexed by the support we now provide.  Pid
>> files are used for lots of things, but we've evolved ours so that it
>> can't support a critical function.  We can't use the file to provide
>> exclusive access.  I'm going to add a configuration variable, so you
>> can specify the number of concurrent argi that can use a given
>> interface.
>> 
>> Currently we support 5 concurrent argi per interface, bit it is hard
>> coded.
>> 
>> Would this be helpful to you?
>> 
>> Carter
>> 
>> 
>> On Jun 27, 2011, at 7:53 PM, Carter Bullard <carter at qosient.com>
>> wrote:
>> 
>>> Russell, Use only one argus to process both interfaces. Look at the
>>> new argus.conf file, in argus-3.0.4 or argus-3.0.5.4, and have one
>>> argus open both interfaces "ind"ependantly. Give them different
>>> srcid's like this:
>>> 
>>> ARGUS_INTERFACE=ind:en0/192.168.0.39,en1/192.168.1.39
>>> 
>>> or use two declarations ARGUS_INTERFACE=en0/192.168.0.39 
>>> ARGUS_INTERFACE=en1/192.168.1.39
>>> 
>>> Carter
>>> 
>>> On Jun 27, 2011, at 9:40 PM, Russell Fulton wrote:
>>> 
>>>> 
>>>> On 28/06/2011, at 1:13 PM, Russell Fulton wrote:
>>>> 
>>>>> Wow, long time no posts :)  Yes I'm still doing things with
>>>>> argus -- just totally snowed under :(
>>>>> 
>>>>> I am currently reworking the management of my sensors and using
>>>>> puppet to do all the heavy lifting and I have got the to the
>>>>> point that I really want to be able to specify the name of the
>>>>> pid file as well as the path.  I could make separate
>>>>> directories for the various argus processors but I would much
>>>>> rather not.
>>>>> 
>>>>> Currently I am running multiple argus processes on one
>>>>> interface but I am only getting one pid file argus.eth1.0.pid
>>>>> 
>>>>> The two processes are spawned very close together and I suspect
>>>>> there is a race condition where the files are being
>>>>> overwritten.
>>>>> 
>>>>> Google turns up a reference to a config option
>>>>> ARGUS-PID-FILENAME but it does not appear to be current.
>>>>> 
>>>>> Have I missed something?
>>>>> 
>>>>> Russell
>>>>> 
>>>>> PS.  running 3.0.2 if it matters....
>>>> 
>>>> I tried putting a two second sleep in the script that spawns the
>>>> process but it did not make any difference, the second process
>>>> seems to overwrite:
>>>> 
>>>> 19911 ?        Ss     0:01 /usr/sbin/argus -F
>>>> /home/sensors/dmzo/conf/argus-std.conf 19913 ?        Ss     0:01
>>>> /usr/sbin/argus -F /home/sensors/dmzo/conf/argus-user-data.conf 
>>>> [sensors at mon263550 ~]$ ls dmzo/run/ argus.eth1.0.pid 
>>>> [sensors at mon263550 ~]$ cat dmzo/run/argus.eth1.0.pid 19913
>>>> 
>>>> Even putting a 10 sec delay made no difference I still got just
>>>> one pid file.
>>>> 
>>>> Russell
>>>> 
>>>> 
>>>> 
>>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110715/00fa48d2/attachment.bin>