pid files...

[Phillip Deneault]

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
>>> 
>>> 
>>> 
>>