Right now the sending of the trigger_action_foo message to the client is done asynchronously to the WOL. This may lead to the situation that the trigger_action_foo message is sent during a running softupdate or installation. This can cause a variety of issues in particular when a gosa-si-client is on the receiving end.
I have the suspicion that this issue may be the cause of failed softupdates that look like LDAP failures during ldap2fai. My suspicion is that while ldap2fai is running or just before it starts running, gosa-si-client gets the delayed trigger_action_foo message which causes a re-registration and a re-writing of the /etc/ldap config files which may cause ldap2fai to fail. It seems very unlikely that this should happen so often but it's the best explanation I have at this time.
To fix: Try to send the trigger_action_foo message with a timeout of a few seconds. Do not send the WOL until the attempt has either failed or succeeded. In fact, it's probably best to not send the WOL at all if the attempt has succeeded because in that case the client will reboot on its own.
From mux2...@gmail.com on April 01, 2014 15:47:17
Right now the sending of the trigger_action_foo message to the client is done asynchronously to the WOL. This may lead to the situation that the trigger_action_foo message is sent during a running softupdate or installation. This can cause a variety of issues in particular when a gosa-si-client is on the receiving end.
I have the suspicion that this issue may be the cause of failed softupdates that look like LDAP failures during ldap2fai. My suspicion is that while ldap2fai is running or just before it starts running, gosa-si-client gets the delayed trigger_action_foo message which causes a re-registration and a re-writing of the /etc/ldap config files which may cause ldap2fai to fail. It seems very unlikely that this should happen so often but it's the best explanation I have at this time.
To fix: Try to send the trigger_action_foo message with a timeout of a few seconds. Do not send the WOL until the attempt has either failed or succeeded. In fact, it's probably best to not send the WOL at all if the attempt has succeeded because in that case the client will reboot on its own.
Original issue: http://code.google.com/p/go-susi/issues/detail?id=169