We have observed the following error messages in production on different Leap 15.4 machines:
Sep 27 07:18:52 openqa systemd[1]: Starting Update system wide CA certificates...
Sep 27 07:18:53 openqa update-ca-certificates[7397]: p11-kit: couldn't complete writing of file: /var/lib/ca-certificates/ca-bundle.pem.tmp: Unknown error 17
Sep 27 07:18:53 openqa systemd[1]: ca-certificates.service: Main process exited, code=exited, status=1/FAILURE
Sep 27 07:18:53 openqa systemd[1]: ca-certificates.service: Failed with result 'exit-code'.
Sep 27 07:18:53 openqa systemd[1]: Failed to start Update system wide CA certificates.
Jun 18 03:01:48 schort-server systemd[1]: Starting Update system wide CA certificates...
Jun 18 03:01:49 schort-server update-ca-certificates[29527]: mv: cannot stat '/var/lib/ca-certificates/ca-bundle.pem.new': No such file or directory
Jun 18 03:01:49 schort-server systemd[1]: ca-certificates.service: Main process exited, code=exited, status=1/FAILURE
Jun 18 03:01:49 schort-server systemd[1]: ca-certificates.service: Failed with result 'exit-code'.
Jun 18 03:01:49 schort-server systemd[1]: Failed to start Update system wide CA certificates.
Restarting the service helps.
Since the /usr/sbin/update-ca-certificates script is started automatically by a path unit and also by via a %post-hook on package updates there might be a chance that the script is running concurrently leading to race conditions and eventually to sporadic errors like these. Maybe it would make sense to add/improve locking.
We have observed the following error messages in production on different Leap 15.4 machines:
Restarting the service helps.
Since the
/usr/sbin/update-ca-certificatesscript is started automatically by a path unit and also by via a %post-hook on package updates there might be a chance that the script is running concurrently leading to race conditions and eventually to sporadic errors like these. Maybe it would make sense to add/improve locking.