Univention Bugzilla – Bug 50403
ucs_registerLDAPExtension --udm_syntax does not wait for the listener
Last modified: 2019-12-04 19:13:53 CET
Created attachment 10215 [details] join.log ucs_registerLDAPExtension --udm_syntax does not wait for the listener At least the join log suggest that ucs_registerLDAPExtension doesn't wait for the listener to write the new syntax to "/usr/share/pyshared/univention/admin/syntax.d/" but instead it waits for the file path that should be registered. For example "/usr/share/univention-office365/handler.d/office365profile.py" I installed the office365 app and I think the join script failed due to this. From the join.log ''' Waiting for activation of the extension object settings/office365profile: OK Waiting for file /usr/share/univention-office365/handler.d/office365profile.py: OK Terminating running univention-cli-server processes. Object exists: cn=office365,dc=univention,dc=intranet Object exists: cn=profiles,cn=office365,dc=univention,dc=intranet unknown module settings/office365profile. Available Modules are: ... ''' This might not be a problem for slave servers, because they wait for the replication to the local ldap which implies waiting for the listener. Idea: use something similar to the "import_syntax_files" function in udm, to check that the syntax has been installed.
Created attachment 10216 [details] listener.log
I think the reason is a missing restart of the UDM CLI Server: diff --git 40univention-office365.inst 40univention-office365.inst index 5d08ee1..f5687d0 100755 --- 40univention-office365.inst +++ 40univention-office365.inst @@ -95,6 +95,8 @@ udm container/cn create "$@" --ignore_exists \ --set name="profiles" \ --set description="Container for Office 365 profiles" || die +pkill -f univention-cli-server + # Create first Profile udm settings/office365profile create "$@" --ignore_exists \ --position="cn=profiles,cn=office365,$ldap_base" \
Turns out this was not the problem and is not really a problem generally. ucs_registerLDAPExtension --udm_syntax does wait for the activation attribute to be set to true, which is set only after the listener wrote out the syntax. The problem was that the univention-cli-server was blocking signals and was therefore not restarted! ''' root@qa442:~# ps -eo blocked,pid,cmd | egrep -v '^0+ ' BLOCKED PID CMD 7be3c0fe28014a03 1 /sbin/init splash 0000000400004a02 238 /lib/systemd/systemd-journald 0000000000014003 282 /lib/systemd/systemd-udevd 0000000200000001 402 /lib/systemd/systemd-logind 0000000000010000 451 runsvdir -P /etc/service log: fffffffe3bfa2800 700 /usr/bin/containerd fffffffe3bfa2800 701 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock 0000000000015027 17363 [univention-cli-] <defunct> 0000000000010000 17495 -bash 0000000000010000 25224 /bin/bash /usr/bin/univention-welcome-screen 0000000000015027 25574 /usr/bin/python2.7 /usr/share/univention-directory-manager-tools/univention-cli-server ''' Keyword: SIGPROCMASK I have no clue how that happened and I can't reproduce this. (I do have a snapshot of this though)
(In reply to Florian Best from comment #2) > I think the reason is a missing restart of the UDM CLI Server: > > diff --git 40univention-office365.inst 40univention-office365.inst > index 5d08ee1..f5687d0 100755 > --- 40univention-office365.inst > +++ 40univention-office365.inst > @@ -95,6 +95,8 @@ udm container/cn create "$@" --ignore_exists \ > --set name="profiles" \ > --set description="Container for Office 365 profiles" || die > > +pkill -f univention-cli-server > + > # Create first Profile > udm settings/office365profile create "$@" --ignore_exists \ > --position="cn=profiles,cn=office365,$ldap_base" \ ucs_registerLDAPExtension "$@" --udm_module ... does attempt to restart the univention-cli-server by doing exactly that :) The univention-cli-server just ignored that signal completely :( see comment 3.
(In reply to Jürn Brodersen from comment #4) > The univention-cli-server just ignored that signal completely :( see comment > 3. AFAIR signals are ignored by the listener, if the listener is currently initializing/resync a listener module.
(In reply to Sönke Schwardt-Krummrich from comment #5) > (In reply to Jürn Brodersen from comment #4) > > The univention-cli-server just ignored that signal completely :( see comment > > 3. > > AFAIR signals are ignored by the listener, if the listener is currently > initializing/resync a listener module. listener != univention-cli-server
ps: root 25574 0.0 0.4 500320 38072 ? Ss 22:14 0:00 /usr/bin/python2.7 /usr/share/univention-directory-manager-tools/univention-cli-server root 17363 0.0 0.0 0 0 ? Z 22:29 0:00 \_ [univention-cli-] <defunct> → The daemon is a zombie process. Don't know what one can do to debug this. gdb -p 25574 (gdb) bt #0 0x00007f01a9dad5e3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x000055a81cf00119 in select_select.lto_priv () at ../Modules/selectmodule.c:267 #2 0x000055a81ce2c84a in call_function (oparg=<optimized out>, pp_stack=0x7ffece5730a8) at ../Python/ceval.c:4352 #3 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #4 0x000055a81ce3214f in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=0x7ffece5731f8, func=<function at remote 0x7f01a91f9410>) at ../Python/ceval.c:4437 #5 call_function (oparg=<optimized out>, pp_stack=0x7ffece5731f8) at ../Python/ceval.c:4372 #6 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #7 0x000055a81ce3214f in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=0x7ffece573348, func=<function at remote 0x7f01a91f9668>) at ../Python/ceval.c:4437 #8 call_function (oparg=<optimized out>, pp_stack=0x7ffece573348) at ../Python/ceval.c:4372 #9 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #10 0x000055a81ce2a9f5 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584 #11 0x000055a81ce2a7b9 in PyEval_EvalCode (co=<optimized out>, globals=<optimized out>, locals=<optimized out>) at ../Python/ceval.c:669 #12 0x000055a81ce5abff in run_mod.lto_priv () at ../Python/pythonrun.c:1376 #13 0x000055a81ce55b52 in PyRun_FileExFlags () at ../Python/pythonrun.c:1362 #14 0x000055a81ce5569e in PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:948 #15 0x000055a81ce06771 in Py_Main () at ../Modules/main.c:640 #16 0x00007f01a9cec2e1 in __libc_start_main (main=0x55a81ce060a0 <main>, argc=2, argv=0x7ffece573788, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffece573778) at ../csu/libc-start.c:291 #17 0x000055a81ce05f9a in _start ()