Univention Bugzilla – Bug 38048
UMC-Server: LockTimeout on startup if server already runs
Last modified: 2019-01-03 07:17:51 CET
If UMC alredy is started and one tries to start it the following traceback is written to the logfile. Instead a message should be displayed "UMC-Server already active". 13.03.15 05:34:25.584 MAIN ( ERROR ) : Traceback (most recent call last): File "/usr/sbin/univention-management-console-server", line 210, in <module> umc_daemon.do_action() File "/usr/lib/pymodules/python2.7/daemon/runner.py", line 186, in do_action func(self) File "/usr/lib/pymodules/python2.7/daemon/runner.py", line 121, in _start self.daemon_context.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 LockTimeout
One example how to reproduce is: for i in 1 2 3; do invoke-rc.d univention-management-console-server start & done Related to Bug #38019 ?
Created attachment 6775 [details] patch
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.