Univention Bugzilla – Bug 54067
Move from S4 ignored in S4-Connector
Last modified: 2022-03-15 08:18:09 CET
Created attachment 10865 [details] connector-s4.log Sometimes in our UCS5 test environment, all tests that tests moving objects in s4 fail at once These are: 52_s4connector.170sync_ad_move_user 52_s4connector.189sync_ad_move_container 52_s4connector.199sync_ad_move_ou 52_s4connector.199sync_ad_move_ou_casemix 52_s4connector.269read_ad_move_object_from_ignore_subtree 52_s4connector.270read_ad_move_user 52_s4connector.500test_user_sync 52_s4connector.500test_group_sync We saw this behaviour at least three times now and activated debugging in one of them to analyse this further. In 270read_ad_move_user a user is moved in s4 (read mode) from cn=users to cn=wprveluc at 03:49:01.01967341 the test then waits until 03:49:18.01536741 to check if the object was moved in UCS. It is still in cn=users. Then at the cleanup it sucessfully deletes the object from the position cn=wprveluc in S4. The object therefore was moved in S4. In the logs we can see that at the time where the object was moved in S4, the S4-Connector polled without recognizing any changes from 03:48:49.596 to 03:49:24.734. The next operation is the cleanup deletion. I attached the connector-s4.log An interesting move with debug level 5 is of the user cn=sghdelpe at 03:49.
Happened again (on two machines in 5.0-1): http://jenkins.knut.univention.de:8080/job/UCS-5.0/job/UCS-5.0-1/job/S4Connector/cfg=master-s4connector/lastCompletedBuild/testReport/52_s4connector/ http://jenkins.knut.univention.de:8080/job/UCS-5.0/job/UCS-5.0-1/job/S4Connector/cfg=update-master-s4connector/lastCompletedBuild/testReport/
<https://jenkins.knut.univention.de:8181/job/UCS-5.0/job/UCS-5.0-1/job/S4Connector/84/> > 52_s4connector.270read_ad_move_user.master091c (since 6) > 52_s4connector.270read_ad_move_user.master071c (since 7)
In the s4 connector logs we could see that a move operation in Samba did not increase the usnChanged. I therefore increased the samba debug level in test test/ucs-test/tests/52_s4connector/270read_ad_move_user. This night, the issue occured again, but was "fixed" by the samba restart that was done to increase the debug level, so we have no additional logs.