SOLVED: Overactive monit eating my CPU time

[andyfitter]

Hi,

I recently installed Amahi 7 on my HP Microserver (which was previously running a much older version perfectly well) I initially had some issues with the headless dvd install and my onboard network card - the device name wasn't eth0 and the whole process seemed to complete ok but be fundamentally broken.

I then reinstalled from a vanilla minimal Fedora install and installed Amahi on top of that, as outlined in the Wiki. all seems mostly ok now apart from an annoying problem:

I have installed a number of apps, including

Logitech Squeezeserver
Subsonic
Amahi VPN
CrashPlan
VNC
TimeMachine

They all seem to work fine. My problem is that monit thinks that isnt the case. It regularly eats 60% of my cpu whilst telling me the following

[GMT Mar 26 17:17:16] error : 'afpd' process is not running
[GMT Mar 26 17:17:16] info : 'afpd' trying to restart
[GMT Mar 26 17:17:16] info : 'afpd' start: /usr/bin/systemctl
[GMT Mar 26 17:17:46] error : 'afpd' failed to start
[GMT Mar 26 17:18:46] error : 'vncserver-4' process is not running
[GMT Mar 26 17:18:46] info : 'vncserver-4' trying to restart
[GMT Mar 26 17:18:46] info : 'vncserver-4' start: /usr/bin/systemctl
[GMT Mar 26 17:19:16] error : 'vncserver-4' failed to start
[GMT Mar 26 17:19:16] error : 'afpd' process is not running
[GMT Mar 26 17:19:16] info : 'afpd' trying to restart
[GMT Mar 26 17:19:16] info : 'afpd' start: /usr/bin/systemctl
[GMT Mar 26 17:19:46] error : 'afpd' failed to start
[GMT Mar 26 17:20:46] error : 'vncserver-4' process is not running
[GMT Mar 26 17:20:46] info : 'vncserver-4' trying to restart
[GMT Mar 26 17:20:46] info : 'vncserver-4' start: /usr/bin/systemctl

Both the failing checks are on PID files that dont actually exist - However the services they are checking seem to be working fine.

I wouldnt normally be too bothered, but monit is taking up a big chunk of my CPU too for some reason.

Any ideas whats up? Is this just a symptom of the Apps still being in beta and not writing their pid files to the right place?

[bigfoot65]

Quite possibly there is something amiss.

When did you install the apps? Are you running the latest Amahi platform? Should be 7.2 if I remember correctly.

Please check the /var/log/amahi-app-installer.log for errors as well. I will take peek at VNC and see if I can see an issue with the PID file. Not familiar with Time Machine, so may have to leave that one for cpg.

If you want to keep them from checking for the PID, edit /etc/monit.d/filename and comment out the checks or remove the file from that directory. Then restart monit.

[andyfitter]

Thanks. Everything was installed a couple of days ago on a new blank drive - My new system reports as:

System 3.13.6-100.fc19.x86_64 ,x86_64
Platform 7.2-1
Core 5.1.4-1

Both installs seemed to go fine:

======= app install begin @ 2014-03-26 08:09:31 +0000 ==========
Installing app id k7q32dwinp under /var/hda/platform/html/script/.. ENV=production
ln -s '/usr/lib/systemd/system/vncserver@4.service' '/etc/systemd/system/multi-user.target.wants/vncserver@4.service'
App: VNC installed
======= app install end @ 2014-03-26 08:23:08 +0000 ==========
======= app install begin @ 2014-03-26 08:25:44 +0000 ==========
Installing app id oxlimkd9bi under /var/hda/platform/html/script/.. ENV=production
Redirecting to /bin/systemctl stop netatalk.service
Redirecting to /bin/systemctl reload monit.service
App: Amahi Time Machine installed
======= app install end @ 2014-03-26 08:25:54 +0000 ==========


There are also a bunch of pending Fedora updates - Is it OK to install them?

[andyfitter]

FYI: Disabling the two failing tests in monit has fixed the CPU issues - I guess it was assuming VNC/AFP was down and attempting to restart it every minute or so, which is quite a heavyweight operation.

Might not be noticeable on a lot of machines, but on my underpowered HP N40L it was causing pretty substantial performance issues.

[bigfoot65]

Good to hear. Will be working on the PID issue with VNC.

[andyfitter]

Looks like afpd fails to start if I comment out the monit lines - I guess it relies on it to start up initially

Managed to make a fix by editing

/usr/libexec/netatalk/netatalk.sh

Added an argument to the afpd call to make it write a pidfile

if [ x"${AFPD_RUN}" = x"yes" -a -x ${ATALK_SBIN}/afpd ]; then
${ATALK_SBIN}/afpd ${AFPD_UAMLIST} -g ${AFPD_GUEST} \
-c ${AFPD_MAX_CLIENTS} -n ${ATALK_NAME}${ATALK_ZONE} -P /var/run/afpd.pid
fi

[bigfoot65]

Should not depend on the monit file.

You can move the .conf file to another directory, then start the service manually. This would only be needed once as the service should run on boot and monit would not try to start or stop it any longer.

The change you made is a work around I suppose. Always best when you don't have to modify an apps files.

Just my 2 cents.

[andyfitter]

Yep, I realise that, but the only way I can see of passing in the '-P' argument into afpd (To make it write a pid file) is by editing that file. Maybe there is a way of doing it via afpd.conf, but nothing correct came to light - You could do it by hijacking one of the other parameters that is passed in via the conf, and adding the '-P' part there I guess.

It seemed to me that afpd just didnt start unless monit kicked it alive initially - maybe it's another issue in Time Machine that needs looking at.

[bigfoot65]

Will have to look, but I would think the -P for the PID could be added to the service. I don't have any Apple machines, so cannot test it thoroughly.

I will see what I can do and post back here.

[ambient711]

having the same issue. Was this ever resolved? Thanks