Bug 22383 - Listener lässt sich doppelt starten, der "normale" gerät dadurch durcheinander
Listener lässt sich doppelt starten, der "normale" gerät dadurch durcheinander
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UNSTABLE
Other Linux
: P5 normal (vote)
: UCS 4.1-2-errata
Assigned To: Philipp Hahn
Arvid Requate
:
: 27335 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-03 16:34 CEST by Arvid Requate
Modified: 2016-07-21 15:15 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2011-05-03 16:34:40 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...
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2012-05-02 11:11:57 CEST
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.
Comment 2 Moritz Muehlenhoff univentionstaff 2013-05-31 10:44:39 CEST
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.
Comment 3 Philipp Hahn univentionstaff 2014-04-10 18:42:15 CEST
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.
Comment 4 Philipp Hahn univentionstaff 2016-06-07 14:53:04 CEST
*** Bug 27335 has been marked as a duplicate of this bug. ***
Comment 5 Philipp Hahn univentionstaff 2016-06-07 18:13:59 CEST
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
Comment 6 Philipp Hahn univentionstaff 2016-06-28 13:02:59 CEST
r70670 | Bug #22383 UDL: Fix spelling mistake
Comment 7 Arvid Requate univentionstaff 2016-07-15 15:57:52 CEST
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
Comment 8 Janek Walkenhorst univentionstaff 2016-07-21 15:15:53 CEST
<http://errata.software-univention.de/ucs/4.1/215.html>