Configuration file parser buggy/too strict

[sleinen]

From [email protected] on March 09, 2011 16:32:24

What steps will reproduce the problem? n/a What is the expected output? What do you see instead? the device should be displayed in the Netflow Tracker What version of the product are you using? On what operating system? Older version of Samplicator. Red Hat rel.5 is the platform Please provide any additional information below. Our Samplicator is running fine, however one thing I noticed is that when I am adding new devices it doesn't seem to display the new device to the Netflow Tracker. But for older device entries, the samplicator continuous to export data to the Tracker no problem at all. What could be a possible cause that hampers the samplicator to export new list of devices after adding to samplicator.conf file?

Original issue: http://code.google.com/p/samplicator/issues/detail?id=4

[sleinen]

From [email protected] on March 09, 2011 13:30:28

Samplicator reads its configuration file only on startup. Could that be your problem? A possible enhancement would be for it to re-read its configuration file when it receives a HUP signal, like some other daemons do.

Labels: -Type-Defect Type-Enhancement

[sleinen]

From [email protected] on March 10, 2011 00:14:23

What do you mean by "Its configuration file is only read at startup"? Like after a physical reboot? And what possible enhancement are you suggesting?

[sleinen]

From [email protected] on March 14, 2011 11:00:37

By "Samplicator reads its configuration file only on startup", I mean the following: The "samplicate" program only reads its configuration file once, namely when it - the samplicate program - is started. (Note that this is only relevant when samplicate is asked to use a configuration file at all, i.e. when the "-c" argument is used.) A possible enhancement would be to add the possibility to tell a running "samplicate" process to re-read its configuration file. Some other Unix daemons re-read their configuration when they receive a "HUP" signal (e.g. "kill -1 "). That is something that could probably be implemented for the samplicator. But someone would have to volunteer to do it. Personally I'm not motivated enough, because there's always the workaround of stopping (killing) and restarting the process. That said, from your description it's not even clear that the root of your problem is the samplicator. You said you are using a "Netflow Tracker". I don't know this tool, but maybe it also needs to be told when a new source is added.

[sleinen]

From [email protected] on September 26, 2011 07:25:35

The reporter didn't respond to my request for additional information, so I conclude that he was able to solve the issue by himself, or that it is not that important to him. It is also not clear whether the issue is with samplicate or with the "downstream" flow consumer (Netflow Tracker).

It would still be an improvement if samplicate would reload its configuration upon receipt of a SIGHUP. But I don't consider this critical, because samplicate can be stopped and restarted if necessary - it is very quick to start up. Therefore I'm lowering the priority to "Low".

Labels: -Priority-Medium Priority-Low

[sleinen]

From [email protected] on September 28, 2011 05:50:39

Hi my apology for the very late response. However, I indeed was able to get the solution directly from the samplicator.conf file which is the txt file being read by the samplicate process. One thing I noticed is that "many spaces every after a line indeed made a difference" which means after i deleted extra spaces (no quote #), the devices are now displayed properly on the our Netflow Tracker.

[sleinen]

From [email protected] on September 30, 2011 15:06:32

Thanks. The configuration file parser in the currently released code (1.3.6) may well have bugs. When studying the source, I noticed that it seemed to ignore all lines where a `#' character occurred anywhere - I think it should only ignore those that start with a hash.

As part of extensive modifications for IPv6 support, I have largely rewritten the parser, and the new one shouldn't have that particular problem anymore. The code is in the trunk, as of revision r126 . It would be great if you could check whether this code handles your old configuration file better. I haven't made a tarball yet, but I can create a "pretest" one if you're interested.

[sleinen]

From [email protected] on March 14, 2012 14:40:33

I'm renaming this issue. The fix is probably already in the trunk, because the configuration-file parsing code has been largely rewritten.

Summary: Configuration file parser buggy/too strict
Status: Started