These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Cron collectinfo messages on the new forum.
Web Hosting and Cloud Computing Control Panels
Hi thetitan,
I've checked my root mailbox but couldn't find the automatically-generated email that you quoted.
I am using:
Webmin version 1.360
Virtualmin version 3.46 (Pro)
I only get this instead:
Cron <root@www> run-parts /etc/cron.daily
Anyway, this thread may be useful to you:
http://www.virtualmin.com/forums/webmin/scheduled-cron-job-%11-how-to-di...
Hi thetitan,
Might be best if you submit a support ticket via "Bugs and Issues" link at the bottom the page.
If it looks like a bug or a systemic issue, Jamie and Joe should know about it via the proper channel (i.e. bug tracker).
ah...lifes...good thank you for your suggestion, but I prefer to fix the problem. Because your solution will only hide the problem. The server memory, CPU and performance will continue to be affected.
Joe, any ideas how to solve this?
I dunno. I see it on our Virtualmin.com server only during weekly and sometimes nightly backups (which puts the server under pretty extreme load). If it's happening during your system backups, it's probably harmless...if not, it's probably worth figuring out what is triggering the load.
--
Check out the forum guidelines!
I have switched servers. The last one was a VM on VZ, which by the way is a terrible system. It simply does NOT like Webmin and MySQL. Few days ago a rented a dedicated server and yesterday I finished configuring it. So far I have not received any collectinfo messages. I hope that being a dedicated server there won't be any more issues like this.
I'm seeing the same issue on CentOS 4.6 with Virtualmin 3.57.
I just recently turned on the root account to do some debugging and noticed these flying in every five minutes.
I looked for the process and found this:
<code>root 19791 19789 0 Apr19 ? 00:00:01 [collectinfo.pl] <defunct></code>
(It's been running since April 19th?)
I tried to kill it without success. Kill -9 can't even get rid of it.
<div class='quote'>I looked for the process and found this:
<code>root 19791 19789 0 Apr19 ? 00:00:01 [collectinfo.pl] <defunct></code>
(It's been running since April 19th?)
I tried to kill it without success. Kill -9 can't even get rid of it.</div>
collectinfo is a somewhat heavy process, but it shouldn't stick around forever (on our boxes it runs for about 10-20 seconds every five minutes).
I'm surprised that a kill -9 won't take it out. That seems like a kernel bug, as kill -9 should kill anything.
You could attach strace to that process to see what it's trying to do.
strace -p PID
Where PID should be replaced by the PID of the process. I don't know that it'll give you any useful information, but might.
There aren't currently any known issues with collectinfo, and haven't been for a while, I don't think. (But, as I mentioned, it is pretty heavy, and it touches a LOT of subsystems every time it runs, as it's gathering data from dozens of places, so it's possible that there's a flaw on some systems.)
--
Check out the forum guidelines!
It happens when its collecting the info for packages installed and the repo's are busy or slow and apt, yum or urpmi are stuck at partial downloads.
I have debugged this in the past.
which keeps collectinfo.pl running indef.
<div class='quote'>The last one was a VM on VZ, which by the way is a terrible system. It simply does NOT like Webmin and MySQL.</div>
Yes, Virtuozzo/OpenVZ is known to have one or more serious memory allocation issues. I don't know if it is limited to "oversold" systems, or if it is just endemic in the system. We have not seen the memory allocation problems on our vservers test systems, though (VZ is a fork of vservers).
--
Check out the forum guidelines!