After installing the self service frontend univention-self-service-passwordreset-umc.service can't start due to the following error reported in the journal: Mai 09 22:23:41 slave systemd[1]: Started memcached daemon (univention-self-service instance). Mai 09 22:23:41 slave systemd-memcached-wrapper[30462]: can't find the user self-service-umc to switch to Mai 09 22:23:41 slave systemd[1]: univention-self-service-passwordreset-umc.service: Main process exited, code=exited, status=67/n/a Mai 09 22:23:41 slave systemd[1]: univention-self-service-passwordreset-umc.service: Unit entered failed state. Mai 09 22:23:41 slave systemd[1]: univention-self-service-passwordreset-umc.service: Failed with result 'exit-code'. On the backend the service is able to start.
Needmoreinfo * Is the frontend app installed on a different server that the backend app? * What is the impact that the service cannot be started?
(In reply to Erik Damrose from comment #1) > Needmoreinfo > * Is the frontend app installed on a different server that the backend app? Yes, backend on DC Master, frontend on a DC Slave > * What is the impact that the service cannot be started? At least some UCR vars don't seem to work/take effect. For example I activated the self registration via and still it never showed up in the self service. There surely are some other effects but we had to fix it manually with the customer before I could test everything.
Please be specific in a bug report with that high user pain. We need as much information as possible to reproduce the issue. * What did the setup look like (we know a DC Master and DC Slave are used), erratalevel etc. * Which configuration steps were taken after the app installation * What did you/the customer want so accomplish, what did not work
(In reply to Erik Damrose from comment #3) > Please be specific in a bug report with that high user pain. We need as much > information as possible to reproduce the issue. > * What did the setup look like (we know a DC Master and DC Slave are used), > erratalevel etc. Actually there is a DC Master, 2 DC Backup and a couple of Slaves. (4.4-4 errata579). > * Which configuration steps were taken after the app installation I don't remember the exact details, but the error message from comment#0 is what we got on all slaves. Apparently something tried start the "univention-self-service-passwordreset-umc.service" there while the users "self-service-umc" does not exist. Looking at the univention-self-service-passwordreset-umc.postinst that seems to be correct. The user is only created on the master and backup server roles. Though we're unsure why that service is installed at all on the slave and what tried to enable/start it. > * What did you/the customer want so accomplish, what did not work
This problem still persists. Here's some more background information: # # Environment # UCS: 5.0-9 errata1126 Installed: dhcp-server=12.0 samba4=4.16 self-service=5.0 # # Problem # When installing the self-service app (frontend) on a replica server, then there is no user 'self-service-umc' created. This only happens on the primary or backup servers during the 'univention-self-service-passwordreset-umc.postinst' script. On a replica server the user is not created but the service is not deactivated/masked either, so the service is marked as 'failed'. # # univention-self-service-passwordreset-umc.postinst # if [ "$server_role" = "domaincontroller_master" -o "$server_role" = "domaincontroller_backup" ]; then if ! getent passwd self-service-umc >/dev/null; then adduser --system --ingroup nogroup --home /var/lib/univention-self-service-passwordreset-umc self-service-umc chmod 0700 /var/lib/univention-self-service-passwordreset-umc fi deb-systemd-invoke enable univention-self-service-passwordreset-umc.service deb-systemd-invoke restart univention-self-service-passwordreset-umc.service fi # # univention-self-service-passwordreset-umc.service # root@replica:~# systemctl status univention-self-service-passwordreset-umc.service ● univention-self-service-passwordreset-umc.service - memcached daemon (univention-self-service instance) Loaded: loaded (/lib/systemd/system/univention-self-service-passwordreset-umc.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2024-10-01 11:30:46 CEST; 24h ago Process: 17508 ExecStart=/usr/share/memcached/scripts/systemd-memcached-wrapper /etc/memcached_univention-self-service.conf (code=exited, status=67) Main PID: 17508 (code=exited, status=67) Okt 01 11:30:46 replica systemd[1]: Started memcached daemon (univention-self-service instance). Okt 01 11:30:46 replica systemd-memcached-wrapper[17508]: can't find the user self-service-umc to switch to Okt 01 11:30:46 replica systemd[1]: univention-self-service-passwordreset-umc.service: Main process exited, code=exited, status=67/NOUSER Okt 01 11:30:46 replica systemd[1]: univention-self-service-passwordreset-umc.service: Failed with result 'exit-code'.
Because of this ticket, the partner from the last comment has created another ticket with us in support, because the end customer cannot fully use the self-service on the school replica. Password changes and resets can only be carried out on the primary or backup, which is very inconvenient for the school to keep asking the partner for such things. In a self-created bug report from the partner, there is a self-created solution. Bug #57172 I can't say how helpful this is. I was able to reproduce the misbehavior on my test environment by simply installing the package univention-self-service-passwordreset-umc_5.0.11-3_all.deb on my school replica and thus had the self-service frontend. Primary Node is self-service backend root@dc0:~# univention-app info UCS: 5.0-10 errata1257 Installed: dhcp-server=12.0 office365=5.12 prometheus=2.53.3 radius=5.0 samba4=4.16 self-service=5.0 self-service-backend=5.0 ucsschool=5.0 v7 ucsschool-apis=1.1.0 ucsschool-id-connector=3.0.4 ucsschool-kelvin-rest-api=1.10.3 ucsschool-veyon-proxy=4.9.1.12-ucs1 wekan=6.09-ucs1 4.4/openid-connect-provider=2.2-konnect-0.33.11-2 Upgradable: office365 root@mejneschool2:~# ucr get self-service/backend-server dc0.ucs5schoolhejne.intranet Replica Node: root@mejneschool2:~# univention-app info UCS: 5.0-10 errata1257 Installed: cups=2.2.1 dhcp-server=12.0 radius=5.0 samba4=4.16 self-service=5.0 squid=3.5 ucsschool=5.0 v7 ucsschool-veyon-proxy=4.9.1.12-ucs1 Upgradable: root@mejneschool2:~# dpkg -l | grep univention-self-service ii univention-self-service 5.0.11-3 all Univention Self Service ii univention-self-service-passwordreset-umc 5.0.11-3 all Password reset module for Univention Self Service. Now I looked at the last comment and thought that the system role might be missing there so that the user self-service-umc is also installed on the school replica and proceeded as follows. I had the package repacked once so that I had something to try out. Then I searched for the file postinst and the line in the comment above. As shown in the example below, I added the domaincontroller_slave to the existing server roles and rebuilt and installed the package. Everything has worked very well so far and the service no longer has any error messages. I can't say to what extent this is a good and long-term solution, someone from our dev team would like to take a closer look and assess this, as I don't have the experience to do so. dpkg-deb -R univention-self-service-passwordreset-umc_5.0.11-3_all.deb self/ vim self/DEBIAN/postinst if [ "$server_role" = "domaincontroller_master" -o "$server_role" = "domaincontroller_backup" -o "$server_role" = "domaincontroller_slave" ]; then if ! getent passwd self-service-umc >/dev/null; then adduser --system --ingroup nogroup --home /var/lib/univention-self-service-passwordreset-umc self-service-umc chmod 0700 /var/lib/univention-self-service-passwordreset-umc fi deb-systemd-invoke enable univention-self-service-passwordreset-umc.service deb-systemd-invoke restart univention-self-service-passwordreset-umc.service fi dpkg-deb -b self/ univention-self-service-passwordreset-umc_5.0.11-3_modifiziert.deb dpkg -i univention-self-service-passwordreset-umc_5.0.11-3_modifiziert.deb systemctl status univention-self-service-passwordreset-umc.service ● univention-self-service-passwordreset-umc.service - memcached daemon (univention-self-service instance) Loaded: loaded (/lib/systemd/system/univention-self-service-passwordreset-umc.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2025-05-20 15:17:07 CEST; 2min 13s ago Main PID: 12252 (memcached) Tasks: 10 (limit: 4915) Memory: 1.1M CGroup: /system.slice/univention-self-service-passwordreset-umc.service └─12252 /usr/bin/memcached -m 64 -s /var/lib/univention-self-service-passwordreset-umc/memcached.socket -a 600 -M -u self-service-umc Mai 20 15:17:07 mejneschool2 systemd[1]: Started memcached daemon (univention-self-service instance).
Another customer affected 2025070821000093
(In reply to Mirac Erdemiroglu from comment #6) > Because of this ticket, the partner from the last comment has created > another ticket with us in support, because the end customer cannot fully use > the self-service on the school replica. Password changes and resets can only > be carried out on the primary or backup, which is very inconvenient for the > school to keep asking the partner for such things. > > In a self-created bug report from the partner, there is a self-created > solution. Bug #57172 I can't say how helpful this is. > > I was able to reproduce the misbehavior on my test environment by simply > installing the package > univention-self-service-passwordreset-umc_5.0.11-3_all.deb on my school > replica and thus had the self-service frontend. > > Primary Node is self-service backend > > root@dc0:~# univention-app info > UCS: 5.0-10 errata1257 > Installed: dhcp-server=12.0 office365=5.12 prometheus=2.53.3 radius=5.0 > samba4=4.16 self-service=5.0 self-service-backend=5.0 ucsschool=5.0 v7 > ucsschool-apis=1.1.0 ucsschool-id-connector=3.0.4 > ucsschool-kelvin-rest-api=1.10.3 ucsschool-veyon-proxy=4.9.1.12-ucs1 > wekan=6.09-ucs1 4.4/openid-connect-provider=2.2-konnect-0.33.11-2 > Upgradable: office365 > > > root@mejneschool2:~# ucr get self-service/backend-server > dc0.ucs5schoolhejne.intranet > > > Replica Node: > root@mejneschool2:~# univention-app info > UCS: 5.0-10 errata1257 > Installed: cups=2.2.1 dhcp-server=12.0 radius=5.0 samba4=4.16 > self-service=5.0 squid=3.5 ucsschool=5.0 v7 > ucsschool-veyon-proxy=4.9.1.12-ucs1 > Upgradable: > > root@mejneschool2:~# dpkg -l | grep univention-self-service > ii univention-self-service 5.0.11-3 > all Univention Self Service > ii univention-self-service-passwordreset-umc 5.0.11-3 > all Password reset module for Univention Self Service. > > > Now I looked at the last comment and thought that the system role might be > missing there so that the user self-service-umc is also installed on the > school replica and proceeded as follows. > I had the package repacked once so that I had something to try out. Then I > searched for the file postinst and the line in the comment above. > As shown in the example below, I added the domaincontroller_slave to the > existing server roles and rebuilt and installed the package. Everything has > worked very well so far and the service no longer has any error messages. > > I can't say to what extent this is a good and long-term solution, someone > from our dev team would like to take a closer look and assess this, as I > don't have the experience to do so. > > > > dpkg-deb -R univention-self-service-passwordreset-umc_5.0.11-3_all.deb self/ > > vim self/DEBIAN/postinst > > > if [ "$server_role" = "domaincontroller_master" -o "$server_role" = > "domaincontroller_backup" -o "$server_role" = "domaincontroller_slave" ]; > then > if ! getent passwd self-service-umc >/dev/null; then > adduser --system --ingroup nogroup --home > /var/lib/univention-self-service-passwordreset-umc self-service-umc > chmod 0700 /var/lib/univention-self-service-passwordreset-umc > fi > > deb-systemd-invoke enable > univention-self-service-passwordreset-umc.service > deb-systemd-invoke restart > univention-self-service-passwordreset-umc.service > fi > > > dpkg-deb -b self/ > univention-self-service-passwordreset-umc_5.0.11-3_modifiziert.deb > > dpkg -i univention-self-service-passwordreset-umc_5.0.11-3_modifiziert.deb > > > systemctl status univention-self-service-passwordreset-umc.service > ● univention-self-service-passwordreset-umc.service - memcached daemon > (univention-self-service instance) > Loaded: loaded > (/lib/systemd/system/univention-self-service-passwordreset-umc.service; > enabled; vendor preset: enabled) > Active: active (running) since Tue 2025-05-20 15:17:07 CEST; 2min 13s ago > Main PID: 12252 (memcached) > Tasks: 10 (limit: 4915) > Memory: 1.1M > CGroup: /system.slice/univention-self-service-passwordreset-umc.service > └─12252 /usr/bin/memcached -m 64 -s > /var/lib/univention-self-service-passwordreset-umc/memcached.socket -a 600 > -M -u self-service-umc > > Mai 20 15:17:07 mejneschool2 systemd[1]: Started memcached daemon > (univention-self-service instance). Customer from 2025051621000045 give me the feedback, that this solution solve the issue on the system and they now able to use the self-service without problems.
Workaround available: https://help.univention.com/t/problem-self-service-cant-find-the-user-self-service-umc-to-switch-to/24368
Created attachment 11329 [details] Patch File
univention-self-service.yaml 69140c0fb3c2 | fix(self-service): disable unnecessary systemd service on replicas univention-self-service (7.2.0) 69140c0fb3c2 | fix(self-service): disable unnecessary systemd service on replicas ucs-test (12.2.40) 35b428f74ce4 | test(self-service): add test to ensure service is disabled The univention-self-service-passwordreset-umc service is now disabled on replicas.
The univention-self-service-passwordreset-umc service is only needed on the primary/backup. I'm not sure what was fixed by adding the "self-service-umc" on the replica. The failed service was only a cosmetic issue. We now only enable the service on primary and backups. As far as I can tell the self-service is and was working even before the fix. Please open a new bug if further fixes are needed.
QA: Code review OK YAML: OK Test: OK
<https://errata.software-univention.de/#/?erratum=5.2x165>