You are not logged in.
Hi,
I have a strange issue with my machine where long-running commands are terminated after some time. This occurrence is different from usual, but this one is pretty bad and hindering so that's why I post now. Usually, commands that run for a long time are ended with a hangup, but this one is terminated straight up for no reason.
I never pressed ctrl+c on this command. All I did was leave it alone.
I've Googled a bunch of times for this issue, but never received any results at all. This happens on every terminal session. Alacritty, konsole, even tty has this issue.
The worst thing is, I have no idea where to look for diagnostic logs, so I have nothing to give. Dmesg has nothing and systemd has nothing that I know of either.
I'd love it if someone could help me with this.
My system is a Thinkpad X1 Carbon Gen 11 - Intel 1370P with 64GB of RAM. I am running kernel 6.10rc5 right now, but that says nothing. I've had this issue on every single kernel I've used so far, which includes most of the v6 kernels, a v5 LTS kernel, v6 LTS kernels and normal release kernels. I somehow doubt it's related to that. This does not happen on my desktop pc though.
:: Running post-transaction hooks...
( 1/31) Creating system user accounts...
( 2/31) Registering binary formats...
( 3/31) Updating journal message catalog...
( 4/31) Reloading system manager configuration...
( 5/31) Reloading user manager configuration...
( 6/31) Updating udev hardware database...
( 7/31) Applying kernel sysctl settings...
( 8/31) Creating temporary files...
( 9/31) Reloading device manager configuration...
(10/31) Arming ConditionNeedsUpdate...
(11/31) Updating the MIME type database...
(12/31) Rebuilding certificate stores...
(13/31) Updating module dependencies...
(14/31) Install DKMS modules
==> dkms install --no-depmod ipu6-drivers/0.0.0 -k 6.6.40-1-lts
==> dkms install --no-depmod ipu6-drivers/0.0.0 -k 6.9.9-arch1-1
Error! Bad return status for module build on kernel: 6.9.9-arch1-1 (x86_64)
Consult /var/lib/dkms/ipu6-drivers/0.0.0/build/make.log for more information.
==> WARNING: `dkms install --no-depmod ipu6-drivers/0.0.0 -k 6.9.9-arch1-1' exited 10
==> dkms install --no-depmod v4l2loopback/0.13.2 -k 6.9.9-arch1-1
==> dkms install --no-depmod v4l2loopback/0.13.2 -k 6.6.40-1-lts
==> dkms install --no-depmod openrazer-driver/3.8.0 -k 6.9.9-arch1-1
==> dkms install --no-depmod openrazer-driver/3.8.0 -k 6.6.40-1-lts
[1] 2119852 terminated sudo pacman -Syu
Oh and after this the pacman db was locked. After unlocking the db, pacman had no more actions to take, so I'm a bit scared to reboot now. Who knows what might happen.
Offline
Is it "long running commands" or are you e.g. running OOM and have systemd-oom enabled or so/or is the OOM killer triggered (check dmesg)
Offline
Surprisingly there were some OOM events in dmesg. If those were related, I am not sure.
After a reboot I tested it again, by running dmesg --follow and waiting a while I can trigger the hangup:
... other dmesg stuff
[ 95.413029] wlp0s20f3: authenticate with 62:22:32:25:ff:66 (local address=60:45:2e:4c:f3:38)
[ 95.414622] wlp0s20f3: send auth to 62:22:32:25:ff:66 (try 1/3)
[ 95.466000] wlp0s20f3: authenticated
[ 95.466876] wlp0s20f3: associate with 62:22:32:25:ff:66 (try 1/3)
[ 95.471294] wlp0s20f3: RX AssocResp from 62:22:32:25:ff:66 (capab=0x1111 status=0 aid=14)
[ 95.485310] wlp0s20f3: associated
[ 95.545950] wlp0s20f3: Limiting TX power to 23 (23 - 0) dBm as advertised by 62:22:32:25:ff:66
[ 341.263044] EXT4-fs (nvme0n1p4): error count since last fsck: 6
[ 341.263050] EXT4-fs (nvme0n1p4): initial error at time 1720603540: htree_dirblock_to_tree:1082: inode 12866372
[ 341.263054] EXT4-fs (nvme0n1p4): last error at time 1720603540: htree_dirblock_to_tree:1082: inode 12866371
[1] 4320 hangup sudo dmesg --follow
I doubt the drive errors have anything to do with it. They don't show up alongside this error, this time was just coincidence. They showed up in the follow minutes before it got the hangup. Those drive errors are there, and I don't know how to fix them permanently. When I reboot, I sometimes get dropped into a rescue shell where I then run fsck to fix them, but they always return. (the drive itself is fine I think, and backed up).
Anyway, after running dmesg again, there are no mentions at all about OOM events. Systemd-oom isn't running either, so that didn't do it.
Offline
While interrupting pacman at random points could cause a range of problems, in the specific case quoted it only failed to run some post-transaction hooks which you can run manually / directly yourself.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline