<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.network.nagios.devel">
    <title>gmane.network.nagios.devel</title>
    <link>http://blog.gmane.org/gmane.network.nagios.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8339"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8336"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8335"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8334"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8330"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8319"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8313"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8312"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8311"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8301"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8294"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8291"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8290"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8289"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8288"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8286"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8273"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8267"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8250"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nagios.devel/8250"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8339">
    <title>Perl Module to Parse status.dat</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8339</link>
    <description>&lt;pre&gt;Hi All,

Could anyone point me towards / recommend perl module working with 
status.dat (if it exists), please?

Trying to be current ...v 3.4.x ...

Many Thanks,

- John

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>John</dc:creator>
    <dc:date>2012-05-24T23:34:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8336">
    <title>NDOUtils 1.5.1 Available</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8336</link>
    <description>&lt;pre&gt;Version 1.5.1 of the NDOUtils add-on has now been released. You can 
download NDOUtils from:

https://sourceforge.net/projects/nagios/files/

Changelog follows...

       * Fixed off-by-one error packing data in ndomod.

Eric

&lt;/pre&gt;</description>
    <dc:creator>Eric Stanley</dc:creator>
    <dc:date>2012-05-17T11:20:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8335">
    <title>nagiostats Config Parameters</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8335</link>
    <description>&lt;pre&gt;Everyone,

I played with the "-c" and "-s" Parameters of a 3.2.3's nagiostats today
and noticed the odd behavior shown below. I didn't look at the source
yet, much less write a patch, but I thought you might want to check on
3.3.x and 3.4.x beforehand (and maybe extend t/705nagiostats.t a bit).

Kind regards,
J. Bern

Normal operation:

# N="/usr/local/nagios"
# $N/bin/nagiostats -m -d NUMSVCOK
1659


status.dat has been moved elsewhere (onto a ramdisk):

# strings - $N/bin/nagiostats | grep /nagios/
/usr/local/nagios/etc/nagios.cfg
/usr/local/nagios/var/status.dat
# grep /status.dat $N/etc/nagios.cfg
status_file=/usr/local/nagios/var/spool/status.dat
# strace $N/bin/nagiostats -m -d NUMSVCOK 2&amp;gt;&amp;amp;1 | \
open("/usr/local/nagios/etc/nagios.cfg", O_RDONLY) = 3
open("/usr/local/nagios/var/spool/status.dat", O_RDONLY) = 3


Specifying nagios.cfg explicitly works:

# $N/bin/nagiostats -c $N/etc/nagios.cfg -m -d NUMSVCOK
1659


Specifying status.dat explicitly - no go:

# $N/bin/nagiostats -s $N/var/spool/sta&lt;/pre&gt;</description>
    <dc:creator>Jochen Bern</dc:creator>
    <dc:date>2012-05-11T19:34:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8334">
    <title>Nagios Core 3.4.0 - performance data issues ifcontain apostrophes</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8334</link>
    <description>&lt;pre&gt;Hi list,

i'm having an odd problem with the development machine I installed  
Nagios Core 3.4.0 to.

It took me some time to make sure what the problem acutally is, but  
there must have some change in the performance data handling.

For my setup:
It's two machines running CentOS 5.8 x64, the production-machine is  
Nagios Core 3.3.1 and the development machine is Nagios Core 3.4.0,  
both have the same versions of other packages both have PNP-0.6.17 and  
both have nagios-plugins-1.4.15 - and both have the exact same config  
(except the dev-machine doesn't send email to everyone).

So far about the basics.

I'm having the problem with the check_snmp and check_nt scripts, if  
there is a label (on check_snmp) or a counter (on check_nt) with  
blanks and it's therefor in apostrophes.

So that means, that Nagios is still checking the state of the checks,  
but there is no performance data handled by PNP, as the input is  
invalid.

Let me explain that with an example:

This checks the environment temperature&lt;/pre&gt;</description>
    <dc:creator>shells&lt; at &gt;wannabepunk.de</dc:creator>
    <dc:date>2012-05-10T14:23:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8330">
    <title>Passive checks number of ettempts error</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8330</link>
    <description>&lt;pre&gt;Hi everybody,

I use Nagios, release 3.2.3, in a distributed environment, with a central
server and several colector servers.

For a long time I´m seeing errors on the passive check mechanism on the
central server, as we can see below.

Sometimes, on the central server, the states and number of attempts don´t
follow the correct order, going from SOFT2 to HARD4, for example. However,
on the colector server everything is OK.

Log from Central Server:
Host Up[2012-05-05 01:06:48] HOST ALERT: node;UP;HARD;1;TCP OK - 0.005
second response time on port 135
Host Down[2012-05-05 01:05:40] HOST ALERT: node;DOWN;HARD;4;CRITICAL -
Socket timeout after 10 seconds
Host Down[2012-05-05 01:04:16] HOST ALERT: node;DOWN;SOFT;2;CRITICAL -
Socket timeout after 10 seconds
Host Down[2012-05-05 01:02:55] HOST ALERT: node;DOWN;SOFT;1;CRITICAL -
Socket timeout after 10 seconds

Log from Colector Server:
Host Up[05-05-2012 01:06:31] HOST ALERT: node;UP;SOFT;4;TCP OK - 0.005
second response time on port 135
Host Down[05-05-2012 01:&lt;/pre&gt;</description>
    <dc:creator>Rodney Ramos</dc:creator>
    <dc:date>2012-05-08T15:07:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8319">
    <title>Customized macros not working for contacts</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8319</link>
    <description>&lt;pre&gt;Hi,

I'm running nagios 3.3.1 on sles 10.

I've defined a contact which uses a customized macro called _EMAILCONTACTID

However, when I try to reference this macro, from a script defined to run as part of a service check,  as an environment variable $NAGIOS__CONTACTEMAILCONTACTID, is blank

If I define a customized macro in the service definition, I can see the contents of $NAGIOS_SERVICEEMAILCONTACTID.

I've followed the docs and it does state that you can define a customized macro in a contact definition, so this to me looks like a bug in 3.3.1

When will a fix be available ?

Regards,
Deborah


This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you are not the intended recipient, please delete this e-mail immediately.  Any unauthorised distribution or copying is strictly prohibited.

Whilst Kognitio endeavours to prevent the transmission of viruses via e-mail, we cannot guarantee that a&lt;/pre&gt;</description>
    <dc:creator>Deborah Martin</dc:creator>
    <dc:date>2012-05-03T10:42:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8313">
    <title>Log USERNAME when DISABLING/ENABLINGchecks/notifications...</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8313</link>
    <description>&lt;pre&gt;Hi All
I don't know the technical reason why Nagios developers didn't thought about this:

I know its not a standard syntax for Username to be as part of DISABLING/ENABLING checks/notifications but it would be nice if your team can start thinking about add it as feature in next releases of Nagios.

Its really giving us HARD time to know who trigger the DISABLE and ENABLE checks/notifications among the teams.

This should apply to BOTH: HOST/SERVICE type of DISABLE/ENABLE external commands.

DISABLE_ALL_NOTIFICATIONS_BEYOND_HOST
DISABLE_CONTACTGROUP_SVC_NOTIFICATIONS
DISABLE_CONTACT_SVC_NOTIFICATIONS
DISABLE_HOSTGROUP_PASSIVE_SVC_CHECKS
DISABLE_HOSTGROUP_SVC_CHECKS
DISABLE_HOSTGROUP_SVC_NOTIFICATIONS
DISABLE_HOST_SVC_CHECKS
DISABLE_HOST_SVC_NOTIFICATIONS
DISABLE_PASSIVE_SVC_CHECKS
DISABLE_SERVICEGROUP_PASSIVE_SVC_CHECKS
DISABLE_SERVICEGROUP_SVC_CHECKS
DISABLE_SERVICEGROUP_SVC_NOTIFICATIONS
DISABLE_SERVICE_FLAP_DETECTION
DISABLE_SERVICE_FRESHNESS_CHECKS
DISABLE_SVC_CHECK
DISABLE_SVC_EVENT_HANDLER
DISABLE_SVC_F&lt;/pre&gt;</description>
    <dc:creator>Deepak Kosaraju</dc:creator>
    <dc:date>2012-04-05T02:44:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8312">
    <title>[PATCH] NRPE wait for client to close</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8312</link>
    <description>&lt;pre&gt;Hi,

We have been investigating an issue with nrpe with regard to reuse of
port numbers and client hickups (check_nrpe).

It seems that the closing of the network sockets has a race condition
which can confuse firewalls, NAT-gateways etc. I have seen reports about
this issue in several forms:

- http://permalink.gmane.org/gmane.network.nagios.devel/3037 1)
- http://tracker.nagios.org/view.php?id=305
- http://sourceforge.net/mailarchive/message.php?msg_id=29054957

With my IPv6 patch the bug exposes itself more often if used 
in combination with -b (bind) on the client. I had to consult Stevens' Unix
network programming seriously to find this one.

It appears that if a client is connected with a server that the most
optimal way of closing the connection is that the client takes the
initiative to close() as most modern network protocols do. The server
also has en open socket so it has to close() is at some time too. The
one who closes first sends a FIN to the other side ultimately resulting
in its socket to be&lt;/pre&gt;</description>
    <dc:creator>Leo Baltus</dc:creator>
    <dc:date>2012-04-02T09:10:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8311">
    <title>[PACTH] NRPE IPv6 (updated)</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8311</link>
    <description>&lt;pre&gt;Hi,

Attached patch fixes a small memory leak introduced by my IPv6 patch I
sent earlier, see below.

As I haven't got any reponse on my first post so I'll just resubmit the
complete patch.

Op 02/05/2011 om 17:32:55 +0200, schreef Leo Baltus:

&lt;/pre&gt;</description>
    <dc:creator>Leo Baltus</dc:creator>
    <dc:date>2012-04-02T09:10:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8301">
    <title>NRPE SSL_shutdown patch</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8301</link>
    <description>&lt;pre&gt;Hello,

I came across the same TCP RST issue as reported in
http://tracker.nagios.org/view.php?id=305. I've attached a patch for
nrpe.c, and also check_nrpe.c as pointed out by dnsmichi.

The problem is that when we call SSL_shutdown() only once, the server
sends an SSL shutdown message to the client. The client then responds
with it's own SSL shutdown message, and this ends up in the server's
socket receive buffer. However, since we never consume this message,
the kernel will send a RST to the client when the server process
exits. This pollutes our firewall logs and makes it harder to detect
more serious TCP errors in our monitoring.

The solution is to call SSL_shutdown() at least twice, and up to 4
times to be safe (usually SSL_shutdown() will return 1 after two
calls). There's a good explanation of this behaviour in the links I
provided within the bug report. I won't take up too much space
explaining it here.

Please apply the attached patch. Thanks!

Jari
------------------------------------------------&lt;/pre&gt;</description>
    <dc:creator>Jari Takkala</dc:creator>
    <dc:date>2012-03-29T08:52:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8294">
    <title>Nagios implied and additive inheritance;possible bug?</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8294</link>
    <description>&lt;pre&gt;I'd like to set up Nagios contact_groups in the following way (but it's not
working as expected):
1) In general, contact_groups for a host are notified about problems with the
host and any service on the host.
2) Occasionally, we'd like other contact_groups to be notified about problems
with certain services on the host.

If I'm understanding the documentation at
http://nagios.sourceforge.net/docs/nagioscore/3/en/objectinheritance.html
correctly (I'm running (3.3.1), it indicates that #1 can be done using implied
inheritance and #2 by using additive inheritance, but it's not working as
expected.  I've found other posts from people with the same issue, but never any
resolution.

For example, if I define:

define host{
        host_name               linux-server
        contact_groups          linux-admins
        ...
        }

define service{
        host_name               linux-server
        service_description     l_proc_sshd
        contact_groups          +management
        ...
        }


I would li&lt;/pre&gt;</description>
    <dc:creator>Jim Winkle</dc:creator>
    <dc:date>2012-03-28T16:44:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8291">
    <title>NRPE - performance data larger than 1024B</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8291</link>
    <description>&lt;pre&gt;Hi.

Someone replied to my post on nagios forum, that devel list would be
better for my topic, so I'm repeating my question here.

I'm considering to integrate my Nagios server with Nagiosgraph (and
possibly migrate with performance graphs from Munin). Unfortunately,
some graphs cannot work correctly because of max packet size (e.g.
check_disk for some of my servers).

There is a working patch, see
http://labs.opsview.com/2008/08/enhancing-nrpe-for-large-output/ - it
looks nice and works perfect - I've checked patched nrpe_check (2.12)
with unpatched/patched nagios-nrpe-server.

Is it possible, that some day you include such a patch in nagios upstream?

Best regards,

R.


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
&lt;/pre&gt;</description>
    <dc:creator>Ryszard Łach</dc:creator>
    <dc:date>2012-03-26T09:40:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8290">
    <title>NSCA 2.9.1: problems and fixes</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8290</link>
    <description>&lt;pre&gt;I had a few problems with the latest version 2.9.1 of nsca:

1) The package age in handle_connection_read of the nsca server part
is calculated based on uninitialized values. This resulted in nsca
dropping packages because it thinks they are too old. See nsca.c.patch
which fixes the problem for me.
2) I had problems compiling it for solaris10. Sol10 misses asprintf.
See solaris10.patch. The patch adds code for the missing asprintf, and
makes also changes to configure.in and Makefile.in to compile the
asprintf part depending on which operating system you compile it for.
(I've compiled it for solaris successfully using a cross compiler:
sparc-sun-solaris2.10-gcc (GCC) 4.6.1)
NOTE: after applying this patch you have to run autoconf

Regards,
Matthias
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, &lt;/pre&gt;</description>
    <dc:creator>Matthias Schlachter</dc:creator>
    <dc:date>2012-03-06T04:27:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8289">
    <title>tests compile in t-tap/</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8289</link>
    <description>&lt;pre&gt;just figured that current svn/git head does not compile within t-tap/, 
attached git patch resolves that.
test_checks segfaults for various reasons i've not yet debugged.

&lt;/pre&gt;</description>
    <dc:creator>Michael Friedrich</dc:creator>
    <dc:date>2012-02-13T17:31:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8288">
    <title>NDOUtils 1.5 Available</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8288</link>
    <description>&lt;pre&gt;Version 1.5 of the NDOUtils add-on has now been released. You can 
download NDOUtils from:

https://sourceforge.net/projects/nagios/files/

Changelog follows...

       * Added various performance improvements originally added for 
Nagios XI (Ethan Galstad)
       * Added asynchronous data spooling to increase performance (andree)
       * Fixed to small es array (Michael Friedrich)
       * Fixed wrong type of object_id in ndo2db_save_custom_variables() 
(Michael Friedrich)

Eric

&lt;/pre&gt;</description>
    <dc:creator>Eric Stanley</dc:creator>
    <dc:date>2012-02-03T18:49:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8286">
    <title>NSCA 2.9.1 Available</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8286</link>
    <description>&lt;pre&gt;Version 2.9.1 of the NSCA add-on has now been released. You can download 
NSCA from:

https://sourceforge.net/projects/nagios/files/

Changelog follows...

- Applied patch to allow packets arriving with a future time stamp 
(Daniel Wittenberg)
- Updated server (nsca) to allow packets with older, smaller packet size 
(Eric Stanley)

Eric

&lt;/pre&gt;</description>
    <dc:creator>Eric Stanley</dc:creator>
    <dc:date>2012-01-27T13:59:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8273">
    <title>Proposal for new Feature : Immutable Macro Variables</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8273</link>
    <description>&lt;pre&gt;Hi everyone,

I'd like to have a community discussion on a possible new feature for Nagios.

To start of, I have written a number of plugins that reuse data from
their previous run, for optimization reasons (one time find correct
SNMP OID to pull data based on regex and just pull from that OID
after) and to calculate percent of change from counters values. The
standard way plugins deal with this is by creating temporary files or
using database. I'm not big fan of those approaches - large number of
such files is a maintenance issue and its a a performance disadvantage
to write/read those files, database is an external service and you
want to avoid relying on that and opening/closing connection for every
plugin run. Instead the plugins I write cache this data using nagios
itself. My plugins that do that are check_snmp_netint.pl,
check_sasraid_megaraid.pl and at least 2 others you can find at
http://william.leibzon.org/nagios/. Right now all these plugins output
these "cache" data as part of part of Nagios perf&lt;/pre&gt;</description>
    <dc:creator>William Leibzon</dc:creator>
    <dc:date>2012-01-12T04:49:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8267">
    <title>nsca-2.9 compatability</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8267</link>
    <description>&lt;pre&gt;
I wanted to use Mike Lindsey's new features in nsca-2.9 but found that clients on 2.7.2 were not able to communicate after updating the server. I found this on the Nagios bug tracker:

http://tracker.nagios.org/view.php?id=78

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________
Nagios-devel mailing list
Nagios-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel
&lt;/pre&gt;</description>
    <dc:creator>Andrew Widdersheim</dc:creator>
    <dc:date>2012-01-11T19:16:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8250">
    <title>Cache layer in NSCA?</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8250</link>
    <description>&lt;pre&gt;We're using an external script to handle connection caching for NSCA..  
Once we have X seconds of OCSP and OCHP results queued in the local 
cache, we fire off a batch submission through send_nsca.  One TCP 
connection, one encryption handshake.  Under extreme load, we've been 
having some issues and I'm thinking about re-engineering it.

Only, I think if I do much work, I'd like to add the cache logic to the 
send_nsca binary itself.

Changes would involve adding a cache directory and cache age (and/or max 
cache items) config directives.  Without the new directives, program 
flow would be as normal.  With those directives, any submitted OC*P 
events submitted to send_nsca would get dumped into the cache directory 
until the oldest file exceeds the max cache age, or the number of items 
exceeds the max.  Once either of those are reached the next send_nsca 
call would submit all results at once.

A lockfile mechanism of some sort would be in place to prevent any 
subsequent send_nsca runs that get kicked of&lt;/pre&gt;</description>
    <dc:creator>Mike Lindsey</dc:creator>
    <dc:date>2012-01-03T23:23:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8250">
    <title>Cache layer in NSCA?</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8250</link>
    <description>&lt;pre&gt;We're using an external script to handle connection caching for NSCA..  
Once we have X seconds of OCSP and OCHP results queued in the local 
cache, we fire off a batch submission through send_nsca.  One TCP 
connection, one encryption handshake.  Under extreme load, we've been 
having some issues and I'm thinking about re-engineering it.

Only, I think if I do much work, I'd like to add the cache logic to the 
send_nsca binary itself.

Changes would involve adding a cache directory and cache age (and/or max 
cache items) config directives.  Without the new directives, program 
flow would be as normal.  With those directives, any submitted OC*P 
events submitted to send_nsca would get dumped into the cache directory 
until the oldest file exceeds the max cache age, or the number of items 
exceeds the max.  Once either of those are reached the next send_nsca 
call would submit all results at once.

A lockfile mechanism of some sort would be in place to prevent any 
subsequent send_nsca runs that get kicked of&lt;/pre&gt;</description>
    <dc:creator>Mike Lindsey</dc:creator>
    <dc:date>2012-01-03T23:23:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nagios.devel/8249">
    <title>Pierre SMOROWINSKI est absent(e).</title>
    <link>http://comments.gmane.org/gmane.network.nagios.devel/8249</link>
    <description>&lt;pre&gt;

Je serai absent(e) à partir du  23/12/2011 de retour le 02/01/2012.

Merci de contacter Jean-Michel Daguet (04 93 95 55 84) pour toutes demandes
urgentes.------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________
Nagios-devel mailing list
Nagios-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel
&lt;/pre&gt;</description>
    <dc:creator>Pierre SMOROWINSKI</dc:creator>
    <dc:date>2011-12-30T03:01:24</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.nagios.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.nagios.devel</link>
  </textinput>
</rdf:RDF>

