Fix for the dreaded mumo.pid.lock file bug about mumo HOT 11 CLOSED

This shouldn't happen as long as the process isn't outright killed. What exactly do you mean with "fails to start as a daemon"? Do you have a log trace for such an occurrence?

from mumo.

I added 5680d80 to work around stale PIDs but I still would be interested in what causes this to happen so regularly as to be annoying. It really should only happen in situations like segfaults, hard machine resets and kill -s 9 's.

from mumo.

Traceback (most recent call last):
File “mumo.py”, line 535, in
context.enter()
File “/usr/lib/pymodules/python2.7/daemon/daemon.py”, line 352, in enter
self.open()
File “/usr/lib/pymodules/python2.7/daemon/daemon.py”, line 344, in open
self.pidfile.enter()
File “/usr/lib/pymodules/python2.7/lockfile.py”, line 223, in enter
self.acquire()
File “/usr/lib/pymodules/python2.7/daemon/pidlockfile.py”, line 109, in acquire
super(TimeoutPIDLockFile, self).acquire(timeout, _args, *_kwargs)
File “/usr/lib/pymodules/python2.7/daemon/pidlockfile.py”, line 59, in acquire
super(PIDLockFile, self).acquire(_args, *_kwargs)
File “/usr/lib/pymodules/python2.7/lockfile.py”, line 261, in acquire
raise LockTimeout
lockfile.LockTimeout

Thanks for the quick response, not sure if I get it because it doesn't shutdown properly and I I need to change the defaults, but this is the log that I get and it is fixed by removing the mumo.pid.lock file.

It is also referenced here http://wiki.natenom.com/w/Mumble_Moderator/Install under Problems. So it's not just me, thanks again for the help and great work.

from mumo.

Yeah. That exception is on the next launch after the lock wasn't properly cleaned up. I was wondering more about how mumo was terminated/shutdown before such things happen so I can make sure it's not actually something that can be fixed cleanly. If you saw any correlation / errors there that would be interesting.

In any case. Hope the workaround does the trick for you. If it doesn't please let me know.

ps: This is the first time someone reported this as a issue and I wasn't aware of it being a problem before it. As such calling it "the dreaded" bug is kinda strange ;) Can't fix issues I don't know about.

from mumo.

Yeah sorry for calling it the "dreaded bug" not really what I meant, more so that it is a common bug or at least so it seemed. At any rate I will give the fix a shot and report back, if it has something to do with it not shutting down properly would I need to change the update-rc.d defaults to have it shutdown before murmur does?

Sent from my iPad

On Jun 24, 2015, at 2:17 PM, Stefan Hacker [email protected] wrote:

Closed #3.

—
Reply to this email directly or view it on GitHub.

from mumo.

That would probably be helpful. Do you have an init script for mumo that properly shuts it down at all? Is it working? ;)

from mumo.

I use the Init script that is given in natenoms wiki in the link I copied to you earlier. I just added your new mumo.py and so far it is working but only time will tell if it actually helped on server reboots. I currently changed the update-rc.d to start on 95 and stop on 20 murmur itself is start on defaults which is 20.

If you can see any major flaws in the Init script from the wiki let me know or if you use your own I would love to give it a try as well thank so much.

Sent from my iPad

On Jun 24, 2015, at 4:43 PM, Stefan Hacker [email protected] wrote:

That would probably be helpful. Do you have an init script for mumo that properly shuts it down at all? Is it working? ;)

—
Reply to this email directly or view it on GitHub.

from mumo.

Looks like that creates yet another pidfile itself ;) I'm afraid I don't feel confident in judging whether that script is as good as it could be. It was a contribution by another user. Does it start and stop mumo without mumo complaining about having to break locks at next launch? ;)

from mumo.

Am I looking for this in mumo.log?

Sent from my iPad

On Jun 24, 2015, at 4:57 PM, Stefan Hacker [email protected] wrote:

Looks like that creates yet another pidfile itself ;) I'm afraid I don't feel confident in judging whether that script is as good as it could be. It was a contribution by another user. Does it start and stop mumo without mumo complaining about having to break locks at next launch? ;)

—
Reply to this email directly or view it on GitHub.

from mumo.

It would go to stderr so probably console when starting.

from mumo.

No issues so far with the new mumo patch you implemented if I see that I am having the pid.lock file problem again I will re-post the logs, thanks for the quick response.

from mumo.