pid files...

[Carter Bullard]

Hey Phil,
Getting a since of the needs makes the design go better.
The bug fix is done, but not up on the server yet.
With the bug fix I think we will do much better with multiple argi using multiple interfaces, but you will still miss some info that you need I think.

I like that there are good reasons to use two separate argi.

Radium does support PID files, and I could put it in all the ra* programs pretty quickly.  I'll look into that.

Thanks!!!!!

Carter


Carter Bullard, QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax

On Jun 29, 2011, at 7:04 AM, Phillip Deneault <deneault at WPI.EDU> 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
>>>> 
>>>> 
>>>> 
>>> 
>