24 November 2015 21:22, "Niko Tyni" <[email protected]> wrote: > On Tue, Nov 24, 2015 at 07:25:08AM +0000, [email protected] wrote: > >> I have just finished work on a new module for running continuous pings. At a >> minimum, it works on >> Debian 8 systems with the iputils-ping package installed, although any >> version of ping that >> supports the "-O" flag to report outstanding pings should work. It also >> requires IO::Epoll (Debian >> package libio-epoll-perl), and forks off a ping process for each target, so >> it will result in one >> ping process running continuously per target. >> >> It works by keeping a record of pings on a per-target basis based on the >> output of the ping >> processes, and then returning the recorded data when smokeping polls for the >> data. I have seen some >> requests for similar functionality in past posts, so I thought I would share >> this. > > Very nice, many thanks for your work! > > A few comments; none of this should preclude inclusion in Smokeping > (which is up to Tobi of course; I'm all for it.) > > - did you look at using 'fping -l' for this? I guess it could work with > just one ping process with that > > - I like the way you're keeping open pipes to the ping processes and tracking > them. This could probably be generalized into its own base* module if > there are other useful long running measurement processes... > > - does this recover if the actual ping process dying off for some reason? > It looks like it might, in the $io->close block around L147? (I guess > it's not a common issue, but it would be nice to catch it.) > > - does it handle ping sequence number wraparound? Those numbers are 16-bit > so I guess it could actually happen at some point. There's a record of > max_seq for each pinger, but it doesn't seem to get used anywhere, and > the dropped packet detection doesn't seem to break at wraparound AFAICS? > > - with multiple targets, it might be useful to be able to distribute > these pings more uniformly, so that all targets wouldn't get pinged at > the very same second. Similar concerns apply to basefork.pm I guess, and > probably only start to matter with a massive number of hosts... > > Thanks again, > -- > Niko >
Hi Niko, While responding to your message last night, I realised that I had carried some unneeded functionality across from the standalone script that I was talking about into the smokping module. I also realised that I could use fping to reduce the number of forked processes, as well as being able to use IO::Select, which will be more portable. I have attached the fping module that I have just finished working on to this message, and I will probably just send a pull request for the fping version. For the record, ping processes that were killed off in the previous version were handled cleanly. regards Steven
FPingContinuous.pm
Description: Binary data
_______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
