admin-reporter.pl script spikes cpu for hours

Has the new version been up and running for 24hours at least?

If not, wait 24 hours and try again.  If it has, I assume you have rebooted?

It's been well over 24 hours. Rebooting did not change anything. This process most recently has been running almost 5 hours. You can see the process id is the same as my previous post.

UID        PID  PPID  C STIME TTY          TIME CMD

root      9653  2701 93 14:45 ?        04:57:10 /usr/bin/perl /usr/local/bin/reporter/admin-reporter.pl

I do not know what this process does, but Astaro runs it repeatedly. I have attached an image of my weekly CPU load. Every time the load spike is due to this Perl script.

Unless there is a fix for this quickly forthcoming, it is time to reinstall 7.011.

It looks like this script is some sort of syslog analyzer. When I look at the system log (which is over 12MB), it is full of messages like this:

2007:12:09-00:00:05 (none) syslog-ng[2701]: Error accepting AF_UNIX connection, opened connections: 100, max: 100

The live log shows a continual stream of these messages.

This would lead me to believe, as I previously suspected, that Astaro is configured/compiled with an insufficient number of connections to run both a busy SOCKS5 proxy and the HTTP proxy.

In any case, it would be nice to know what sort of limit of 100 connections is being hit and why.

Lastly, I will add that my inspection of the open connections in Astaro leads me to believe that there is a lot of socket activity going on that the administrator is not made aware of. This worries me. I may have to get some port mirroring going and run a packet sniffer to see what Astaro is really doing. Something just doesn't add up.

It's been well over 24 hours. Rebooting did not change anything. This process most recently has been running almost 5 hours. You can see the process id is the same as my previous post.

UID        PID  PPID  C STIME TTY          TIME CMD

root      9653  2701 93 14:45 ?        04:57:10 /usr/bin/perl /usr/local/bin/reporter/admin-reporter.pl

I do not know what this process does, but Astaro runs it repeatedly. I have attached an image of my weekly CPU load. Every time the load spike is due to this Perl script.

Unless there is a fix for this quickly forthcoming, it is time to reinstall 7.011.

It looks like this script is some sort of syslog analyzer. When I look at the system log (which is over 12MB), it is full of messages like this:

2007:12:09-00:00:05 (none) syslog-ng[2701]: Error accepting AF_UNIX connection, opened connections: 100, max: 100

The live log shows a continual stream of these messages.

This would lead me to believe, as I previously suspected, that Astaro is configured/compiled with an insufficient number of connections to run both a busy SOCKS5 proxy and the HTTP proxy.

In any case, it would be nice to know what sort of limit of 100 connections is being hit and why.

Lastly, I will add that my inspection of the open connections in Astaro leads me to believe that there is a lot of socket activity going on that the administrator is not made aware of. This worries me. I may have to get some port mirroring going and run a packet sniffer to see what Astaro is really doing. Something just doesn't add up.

Looks like your reporting daemon has locked / gone nuts.
Suggest do a backup, then reinstall clean and restore.

Hi,

the reporters are a part of the Reporting subsystem of the ASG that parse certain logging data for relevant information. The admin-reporter is responsible for events like console logins, webadmin logins, up2date authentications/downloads/installs, system restarts, ha takeover, ups or ufo events. Obviously, the admin reporter shouldn't get much data to process compared to the web / email / packetfilter reporter, therefore I don't think that the amount of CPU usage that you experience is "normal" usage.

The syslog error message "Error accepting AF_UNIX connection, opened connections: 100, max: 100" states that it has opened 100 unix-stream connections. This refers to it's data sources ("/dev/log" files, also in various chroots) which should never hit the limit of 100 (since the amount is rather static). It sounds like it somehow got confused with it's file descriptors, please try "/etc/init.d/syslogng stop", wait a bit, see if the process really terminated, then start it again.

The reporter processes are continuously running processes which have their STDIN connected to the syslog-ng process; the syslog server filters log data and forwards them log lines which could contain events they are counting. If the syslog server really is the source of the problem, it is likely that the problem with the admin-reporter is only a aftereffect and will not happen again once things run smooth.

Lastly, regarding socket activity: yes, there is a lot of socket activity which the administrator is not made aware of, since these are the gory internals of the product [;)]. The ASG contains a lot of different, encapsulated components that need to exchange data. For example, configuration is stored in the configuration daemon which is accessed by almost every other component of the ASG. This happens via RPC over sockets, but only using the loopback interface. Try listening on the loopback interface, you'll see a lot of communication being done.

Regards,
 andreas