Univention Bugzilla – Bug 22383
Listener lässt sich doppelt starten, der "normale" gerät dadurch durcheinander
Last modified: 2016-07-21 15:15:53 CEST
Der Listener lässt sich doppelt starten, die Modulabarbeitung des "normalen" gerät dadurch durcheinander (eines der Module wurde z.B. nicht mehr ausgeführt). Im listener.log schreibt der manuell aufgerufene Prozess fortwährend: 03.05.11 16:29:35 LDAP ( ERROR ) : ldap_sasl_interactive_bind: Local error Beispiel: ### listener wird normal gestartet: root@backup:~# /etc/init.d/univention-directory-listener start * Starting univention-directory-listener daemon ...done. root@backup:~# ps ax | grep list 3159 ? Ss 0:00 runsv univention-directory-listener 4192 tty7 Ss+ 0:50 /usr/bin/X :0 :0 -audit 0 -deferglyphs 16 -br -auth /var/lib/gdm/:0.Xauth -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7 17621 ? S 0:01 /usr/sbin/univention-directory-listener -F -b dc=dvs10,dc=local -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -o -d 2 -x -ZZ -D cn=admin,dc=dvs10,dc=local -y /etc/ldap.secret 17853 pts/1 S+ 0:00 grep list ### und scheint keinen pid-file unter folgendem Pfad zu schreiben: root@backup:~# ls -l /var/lib/univention-directory-listener/pid ls: Zugriff auf /var/lib/univention-directory-listener/pid nicht möglich: Datei oder Verzeichnis nicht gefunden ### Mutwilliger Fehler: manueller start des univention-directory-listener: root@backup:~# univention-directory-listener ctrl resync foo 03.05.11 16:26:05 DEBUG_INIT ## dann laufen zwei: root@backup:~# ps ax | grep list 3159 ? Ss 0:00 runsv univention-directory-listener 4192 tty7 Ss+ 0:50 /usr/bin/X :0 :0 -audit 0 -deferglyphs 16 -br -auth /var/lib/gdm/:0.Xauth -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7 17621 ? S 0:01 /usr/sbin/univention-directory-listener -F -b dc=dvs10,dc=local -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -o -d 2 -x -ZZ -D cn=admin,dc=dvs10,dc=local -y /etc/ldap.secret 17913 ? Ss 0:00 univention-directory-listener ctrl resync foo 17921 pts/1 S+ 0:00 grep list ### wird der "richtige" gestoppt: root@backup:~# /etc/init.d/univention-directory-listener stop * Stopping univention-directory-listener daemon ...done. ### bleibt ein pid-file des manuell getarteten: root@backup:~# ls -l /var/lib/univention-directory-listener/pid ---------- 1 root root 5 3. Mai 16:26 /var/lib/univention-directory-listener/pid root@backup:~# cat /var/lib/univention-directory-listener/pid 17913 ### dieser pid file scheint generell mal wichtig gewesen zu sein: root@backuunivention-directory-listener ctrl resync bar 03.05.11 16:27:49 DEBUG_INIT 03.05.11 16:27:49 LISTENER ( ERROR ) : pidfile /var/lib/univention-directory-listener/pid exists, aborting...
An Ticket#: 2012050221002531 auf dem DC Master aufgetreten. Ursache für den Start des zweiten Listeners ist unklar. In der Prozessliste tauchte der zweite/ungewollte Prozess als eigenständiger Prozess (kein runit-Child) und ohne Parameter auf.
We will not ship a UCS 3.1-2 release; the next UCS release will be UCS 3.2. As such, this bug is moved to the new target milestone.
FYI: r49231 fixed a similar issue in the S4 connector by keeping a file open with fcntl.flock(lock_file.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB), which the listener could also adapt.
*** Bug 27335 has been marked as a duplicate of this bug. ***
r69903 | Bug #22383 UDL: Fix exclusive daemonize r69902 | Bug #22383 UDL: Prevent starting multiple listeners Package: univention-directory-listener Version: 10.0.0-11.315.201606071717 Branch: ucs_4.1-0 Scope: errata4.1-2 r69910 | Bug #22383,Bug #30227,Bug #30263,Bug #34324,Bug #34507,Bug #34738,Bug #3490,Bug #38696,Bug #39509,Bug #40600,Bug #41261: UDL YAML univention-directory-listener.yaml
r70670 | Bug #22383 UDL: Fix spelling mistake
Ok, the primary issue has been fixed: I cannot start another UDL when one is already started normally via the chain init > runit > UDL -F, because UDL now holds a traditional process-associated lock on cache.db.lock. Note: The daemonize code, which is of minor importance because it's not used in standard UCS currently doesn't play nice yet: ## PID file mode strange? root# /etc/init.d/univention-directory-listener stop root# /usr/sbin/univention-directory-listener -b dc=ar41i1,dc=qa -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -d 2 -x -ZZ -D cn=admin,dc=ar41i1,dc=qa -y /etc/ldap.secret 24.11.15 15:27:37.031 DEBUG_INIT root# ls -l /var/lib/univention-directory-listener/pid -r--r-s--- 1 root root 5 Nov 24 14:56 /var/lib/univention-directory-listener/pid ## PID file left behind by killed daemonized UDL blocks new daemon: root# pkill -F /var/lib/univention-directory-listener/pid root# /usr/sbin/univention-directory-listener -b dc=ar41i1,dc=qa -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -d 2 -x -ZZ -D cn=admin,dc=ar41i1,dc=qa -y /etc/ldap.secret 24.11.15 15:28:57.263 DEBUG_INIT 24.11.15 15:28:57.263 LISTENER ( ERROR ) : pidfile /var/lib/univention-directory-listener/pid exists, aborting...17 File exists ## No clue why, exit_handler should have removed it? root# rm /var/lib/univention-directory-listener/pid ## I can start two, first one daemonized, second one via runit (i.e. with -F): root# /usr/sbin/univention-directory-listener -b dc=ar41i1,dc=qa -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -d 2 -x -ZZ -D cn=admin,dc=ar41i1,dc=qa -y /etc/ldap.secret 24.11.15 15:30:40.281 DEBUG_INIT root# /etc/init.d/univention-directory-listener start [info] Starting univention-directory-listener daemon. done. root# pgrep -fl /usr/sbin/univention-directory-listener 16849 /usr/sbin/univention-directory-listener -b dc=ar41i1,dc=qa -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -d 2 -x -ZZ -D cn=admin,dc=ar41i1,dc=qa -y /etc/ldap.secret 16865 /usr/sbin/univention-directory-listener -F -b dc=ar41i1,dc=qa -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -d 2 -x -ZZ -D cn=admin,dc=ar41i1,dc=qa -y /etc/ldap.secret Since the "daemonized" child process explicitly keeps the inherited cache.db.lock file descriptor open, I'd suggest that it re-aquires but I currently don't see an easy way to achieve that with traditional process-associated locks without introducing a race condition (i.e. potential gap) between the parent unlocking (by exit) and the child F_LOCKing. Anyway, that's icing on the cake. You already noted that there is more finesse missing, like the 2nd fork. So I'm fine with the achieved improvement. Advisory: Ok
<http://errata.software-univention.de/ucs/4.1/215.html>