System crash leaves stagnant pidfile

[chirss]

In my setup if I have a os/system crash, it leaves behind a stagnant pidfile. This makes sense. However on startup minemeld is set up to start at boot/runlevel 3 or whatever run level. It seems the stagnant pidfile does not in fact get cleaned up so the processes do not start.

If the pidfile were stored in /run then this would not be the fact since it is mounted as tmpfs as far as I understand it. Is this something which could be modified to account for the above scenario with stale pidfiles?

[lmori · Accepted solution]

@chirss you are right, it was an oversight on my side. I would create a directory owned by minemeld user in /run and replace /opt/minemeld/local/supervisor/run with a symbolic link to that directory. Or wait for the next update where I will fix this 🙂

Thanks !

[chirss]

Awesome thanks. I wouldn't have even noticed except I'm running it in vmware workstation and my laptop has problems hibernating.

[lmori]

Should be fixed in the new version of the base apt package, auto update should automatically install it.

[chirss]

Do I need to do anything after running dist-upgrade and it completing?

[lmori]

Hi chirsf,

to update MineMeld you can simply run "sudo /usr/sbin/minemeld-auto-update", this is also referenced in a daily cron job so chance are your system was already up to date.

If you have run a dist-upgrade you can check if the apt base package has been updatded (dpkg -l | grep minemeld), it should show version 0.9.6-1. Upgrading the base package automatically updates the MineMeld code, you can check if you are running the latest release (0.9.24) by doing  a "ls -l /opt/minemeld/engine". You should find symbolic link named "current" pointing to the directory 0.9.24.