After I install packages with zypper in the terminal or tty, post-transaction scripts stall and never finish. Ctrl+C twice does not work; only Ctrl-Z and then killing zypper. This first happened several weeks ago after a zypper dup and, unlike similar reports, is reproducible for me. Should I report a bug and/or how can I troubleshoot?
Running post-transaction scripts -------------------------------------------------------------------------------------------[-]
^C
Trying to exit gracefully...
^X
^Zfish: Job 2, 'sudo zypper in some-package' has stopped
> sudo zypper in some-package
System management is locked by the application with pid 172243 (zypper).
Close this application before trying again.
> sudo kill -9 172243
I ran journalctl -f while reproducing the issue and noticed only kwallet activity.
Log
Jun 26 14:29:07 mycomputer sudo[183519]: pam_kwallet5(sudo:auth): pam_kwallet5: Refusing to do anything for the root user
Jun 26 14:29:11 mycomputer sudo[183519]: ryan : TTY=pts/0 ; PWD=/home/user/current-dir/ ; USER=root ; COMMAND=/usr/bin/zypper in some-package
Jun 26 14:29:11 mycomputer sudo[183519]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Jun 26 14:29:11 mycomputer sudo[183519]: pam_unix(sudo:session): session opened for user root(uid=0) by ryan(uid=1000)
Jun 26 14:29:11 mycomputer sudo[183519]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_open_session
Jun 26 14:29:11 mycomputer sudo[183519]: pam_kwallet5(sudo:session): pam_kwallet5: we were already executed
Jun 26 14:29:11 mycomputer sudo[183519]: pam_unix(sudo:session): session closed for user root
Jun 26 14:29:11 mycomputer sudo[183519]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_close_session
Jun 26 14:29:11 mycomputer sudo[183519]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Thanks. I ran rpm --rebuilddb and tried force installing a package again with no change in results (To be clear, this happens with any package). If this seems like a bug, I would appreciate any suggestions on what logs to look for and include in the report.
I looked at the full journalctl log and noticed this.
Jun 25 22:21:04 mycomputer zypper[1159]: (4/5) Removing: kernel-devel-6.14.6-1.1.noarch [...done]
Jun 25 22:21:06 mycomputer zypper[1159]: (5/5) Removing: kernel-default-6.14.6-1.1.x86_64 [...done]
Jun 25 22:21:06 mycomputer zypper[1159]: Running post-transaction scripts [...done]
Jun 25 22:21:08 mycomputer zypper[1159]:
Apparently, the script does not always fail. However, I am surprised to see “[…done]” in the log, because the time stamp matches when I ran dup and then had to kill zypper after about 10 minutes of waiting for the script to finish.
I suppose what could be happening is trouble with your storage device hosting the root filesystem. Try checking it with smartctl -x for any obvious errors. A forced root filesystem check shouldn’t hurt either. If neither indicate trouble, a bug report could be helpful. I’ve actually encountered a similar failure, but it’s been a while, and I don’t remember being able to reproduce it. I may have done all suggestions I’ve made here before trying zypper again. I use only ext4 and have timered fstrims disabled, so may have run it after fsck too. If you report a bug, you’ll be asked for logs that may be only portions of dmesg, zypper.log, and/or the journal rather than the whole shebang. Zypper.log is immensely verbose by default.
You should start with funding out what process hangs. Post-transaction is not a single script. It is installation stage where scripts installed by individual packages are executed. You need to find out at which point it hangs. Running rpm -vvv may provide more details.
journalctl is not a magic bullet that shows everything that happens on your system.
It does not matter what the hardware of the mass-storage is, nor if it has “plenty of free space”. It matters if the root file system has “plenty of free space”.