Mailinabox: Old management deamon without virtualenv still running after upgrade

[yodax]

The old management deamon is still running after an upgrade and the new one is not. I discovered this because the local access to the service failed:

$ tools/dns_update 
Incorrect username or password

I've checked that the api is written on the start of the service. I saw that stopping the current service failed because the process wasn't found. So we have an api key (new) but not a running process, I think this is because the service couldn't bind to the port.

So I checked the running processes and saw that the deamon was running with an old pid. So I killed that one. After that stopping and starting the service works. Local access is also restored.

I started investigating this since the upgrade gave and error about an incorrect username or password.

I think we should add an hide_output service mailinabox stop to the top of the setup/management.sh. But I have no boxes to test this on at the moment. I will have a look at setting a new one up with the previous release and test an upgrade with that patch.

Users affected by this can reboot or kill the running process and start the service. After that all should be fine.

[KeiroD]

I'd also recommend service mailinabox status so users can determine whether or not the mailinabox daemon is running with the appropriate setting. And during upgrades, maybe a line about checking which location it should be running from.

Something like that, at any rate.

[notEvil]

I found that the start-stop-daemon command in conf/management-initscript used for stopping the old daemon would kill the parent process (bash) but not the child process (python) of the daemon. Adding pkill -P $(cat $PIDFILE) before the start-stop-daemon command solved the issue for me, but its certainly no reasonable fix. Hope to see one in the next release ;)

[JoshData]

Thanks!! That was a big help. Fix committed above.

[yodax]

Thanks for fixing it! Sorry I didn't have the time yet to test a solution.