Rastream doesn't rotate properly when daemonied?

Matt Brown matthewbrown at gmail.com
Tue May 21 09:48:45 EDT 2013


Good morning Carter!




I wrote an init script and had some issues when starting rastream with the
script targetting ~/.rarc even if I set $ARGUSHOME or $HOME within the
script (on CentOS) (due to service's use of /bin/env).





So, the line I use within the init script is:



/usr/local/bin/rastream -d -F /etc/rastream.conf -S 127.0.0.1:561 -B 15s -M
time 1h <x-apple-data-detectors://0> -w /var/opt/argus/%Y-%m-%d/argus_%T -f
/usr/local/bin/rastream.sh



The same problem with timing occurs as had previously occur when relying on
the full ~/.rarc.





Here is an etherpad with relevant information:
https://etherpad.mozilla.org/dmoSdfQ9H4



# rastream --version

Rastream Version 3.0.7.9





Thanks very much Carter!



Matt

On May 21, 2013, at 6:44 AM, Carter Bullard <carter at qosient.com> wrote:


Hey Matt,
So.......any chance you are setting the timezine in a rarc file somewhere,
like /etc/rarc or in your yme directory ?
What version are you running ?

Carter

On May 20, 2013, at 2:42 PM, Matt Brown <matthewbrown at gmail.com> wrote:

Hello All:





I am having a problem with rastream that's manifested itself when using the
-f "shell script executor" argument to rotate files at 'time
1h<x-apple-data-detectors://0>
'.





If I run rastream as a daemon, then the script seems to run before the
"hour" is over (and the "hour" is over at the incorrect time):

# rastream -d -S 127.0.0.1:561 -B 15s -M time 1h<x-apple-data-detectors://1> -w
/var/opt/argus/%Y-%m-%d/argus_%T -f /usr/local/bin/rastream.sh



A few hours' files look like:



# ls --full-time /var/opt/argus/2013-05-18

total 3728

-rw-r--r--. 1 root  18752 2013-05-18 01:00:59.556839459 -0400
argus_00:00:00<x-apple-data-detectors://3>

-rw-r--r--. 1 root 160607 2013-05-18 01:00:17.793286000 -0400
argus_00:00:00.gz

-rw-r--r--. 1 root  12068 2013-05-18 02:00:59.619364943 -0400
argus_01:00:00<x-apple-data-detectors://6>

-rw-r--r--. 1 root 163409 2013-05-18 02:00:17.943700000 -0400
argus_01:00:00.gz

-rw-r--r--. 1 root   9032 2013-05-1803:01:00.579907536 -0400
argus_02:00:00<x-apple-data-detectors://9>

-rw-r--r--. 1 root 122920 2013-05-18 03:00:17.834317000 -0400
argus_02:00:00.gz

-rw-r--r--. 1 root  22092 2013-05-18 04:01:00.698357771 -0400
argus_03:00:00<x-apple-data-detectors://12>

-rw-r--r--. 1 root 122002 2013-05-18 04:00:17.835675000 -0400
argus_03:00:00.gz

-rw-r--r--. 1 root  17704 2013-05-18 05:01:00.450618851 -0400
argus_04:00:00<x-apple-data-detectors://15>

-rw-r--r--. 1 root 133212 2013-05-18 05:00:17.742040000 -0400
argus_04:00:00.gz

-rw-r--r--. 1 root  14592 2013-05-18 06:00:54.886285774 -0400
argus_05:00:00<x-apple-data-detectors://18>

-rw-r--r--. 1 root 160523 2013-05-18 06:00:17.562776000 -0400
argus_05:00:00.gz



It looks like the gzipped file is last modified before the hour file, which
leads me to believe that rastream isn't finished writing to the argus file
before -f[] is executed.





If I run rastream as follows, I have no problem:

# nohup rastream -S 127.0.0.1:561 -B 15s -M time
1h<x-apple-data-detectors://20> -w
/var/opt/argus/%Y-%m-%d/argus_%T -f /usr/local/bin/rastream.sh &



A few hours' files look like:



#  ls --full-time /var/opt/argus/2013-05-20

total 5372

-rw-r--r--. 1 root 217245 2013-05-20 10:00:17.573908000 -0400
argus_09:00:00.gz

-rw-r--r--. 1 root   6377 2013-05-2011:00:17.762140000 -0400
argus_10:00:00.gz

-rw-r--r--. 1 root   9269 2013-05-2011:38:08.879810000 -0400
argus_11:00:00.gz

-rw-r--r--. 1 root    313 2013-05-2013:00:17.170958000 -0400
argus_12:00:00.gz

-rw-r--r--. 1 root   8965 2013-05-2014:00:17.540889000 -0400
argus_13:00:00.gz



(early day over there)







I have verified that the system time is correct and ntpd is running
properly.



Clients are 3.0.7.9.





Carter, do you have any ideas?





Thanks,



Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130521/31014f98/attachment.html>


More information about the argus mailing list