How about LTS kernel? Do you get this same issue?
if it caused by low memory, you can use some swap and zram with oomkiller software like earlyoom
This is my fourth attempt with Clear Linux, but… I somehow don’t want to give up, so I’ve decided to look through the logs again.
There wasn’t a record indicating a kernel crash, but instead, I found a single keyword that consistently appears in the systemctl -f output.
Crash case 1
Aug 06 05:43:35 gosomi2 systemd[1]: clr-power.service: Deactivated successfully.
Aug 06 05:43:35 gosomi2 systemd[1]: Finished clr-power.service. <- ???
Aug 06 05:43:36 gosomi2 pacdiscovery[269]: failed getaddrinfo: No address associated with hostname
Aug 06 05:43:39 gosomi2 pacdiscovery[269]: Unable to find wpad host
Aug 06 05:43:41 gosomi2 systemd[1]: run-docker-runtime\x2drunc-moby-1c340e5ed7959e5ad3d766b8cc2fbc7bd099907d9ee850b707838186dcaa8538-runc.euPqZx.mount: Deactivated successfully.
Aug 06 05:43:45 gosomi2 systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Aug 06 05:43:52 gosomi2 systemd[1]: run-docker-runtime\x2drunc-moby-1c340e5ed7959e5ad3d766b8cc2fbc7bd099907d9ee850b707838186dcaa8538-runc.1FcUYs.mount: Deactivated successfully.
Aug 06 05:43:55 gosomi2 systemd[1]: Created slice system-sshd.slice.
Aug 06 05:43:55 gosomi2 systemd[1]: Starting sshd-keygen.service...
Aug 06 05:43:55 gosomi2 systemd[1]: Finished sshd-keygen.service.
Aug 06 05:43:55 gosomi2 systemd[1]: Started sshd@0-192.168.9.8:22-192.168.9.3:39140.service. <- the crash point
Aug 09 11:16:29 gosomi2 systemd-resolved[249]: Clock change detected. Flushing caches.
Aug 09 11:16:29 gosomi2 systemd-timesyncd[250]: Contacted time server 121.174.142.81:123 (1.clearlinux.pool.ntp.org).
Aug 09 11:16:29 gosomi2 systemd-timesyncd[250]: Initial clock synchronization to Wed 2023-08-09 11:16:29.449313 UTC.
Crash case 2
Aug 11 02:45:54 gosomi2 systemd[1]: run-docker-runtime\x2drunc-moby-1c340e5ed7959e5ad3d766b8cc2fbc7bd099907d9ee850b707838186dcaa8538-runc.a3cKGP.mount: Deactivated successfully.
Aug 11 02:45:54 gosomi2 systemd[1]: Starting clr-power.service... <- ???
Aug 11 02:45:54 gosomi2 systemd[1]: clr-power.service: Deactivated successfully.
Aug 11 02:45:54 gosomi2 systemd[1]: Finished clr-power.service.
Aug 11 02:45:54 gosomi2 pacdiscovery[273]: failed getaddrinfo: No address associated with hostname
Aug 11 02:45:57 gosomi2 pacdiscovery[273]: Unable to find wpad host
Aug 11 02:46:03 gosomi2 systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Aug 11 02:46:14 gosomi2 systemd[1]: run-docker-runtime\x2drunc-moby-1c340e5ed7959e5ad3d766b8cc2fbc7bd099907d9ee850b707838186dcaa8538-runc.gx0wZ5.mount: Deactivated successfully. <- the crash point
Aug 14 03:23:16 gosomi2 systemd-timesyncd[249]: Contacted time server 158.247.195.140:123 (1.clearlinux.pool.ntp.org).
Aug 14 03:23:16 gosomi2 systemd-timesyncd[249]: Initial clock synchronization to Mon 2023-08-14 03:23:16.160491 UTC.
Aug 14 03:23:16 gosomi2 systemd-resolved[248]: Clock change detected. Flushing caches.
Is there a connection between clr-power and the cause of my system entering a zombie state (where only the power is on, but it’s unusable)? If this simply transitions my system into an idle state, why isn’t a recovery feature provided, and why does it cause issues on server systems?
journalctl -f ?
But that is not only service that get finished right? like those sshd-keygen
Oh sorry. It is journalctl
yea, seem our problem with crash are different. Mine seem exclusively affect alder lake cpu and newer
I have gone ahead and increased the swap just in case it might be related to memory. I should be able to ascertain the results in a few days.
However, I still have reservations about Clear Linux. It has led me to question whether the fundamental concept of assigning importance and priorities to processes might differ from other Linux distributions.
While other distributions consider the importance of processes when resources reach their limits, there’s a sense of random termination with Clear Linux. This has raised doubts about whether the frequent triggering of freezing could be linked to this behavior.
Unfortunately, due to the lack of any logs being recorded when freezing occurs in Clear Linux, it’s not possible to confirm the reality of the situation. Not only are there no logs left, but also ICMP tests fail, and yet the system remains powered on in a zombie-like state.
Nonetheless, when I reflect upon why Clear Linux is receiving praise for its high performance, it’s not difficult to comprehend.
1 Like
i would recommend setup oomkiller, i use earlyoom, its available on clearlinux
Despite the efforts mentioned above, I have observed today that my Clear Linux froze as usual. This might also be a case where no logs are recorded, making debugging impossible.
After applying earlyoom following a hard reset, I will provide the test results again.
Um… I tried applying EarlyOOM, but the memory management strategy seems too aggressive. It feels like it kills off processes that are using even a small amount of swap space for a certain period of time.
This implies that any process requesting swap space is considered a faulty process. Since in other distributions, users are guaranteed the ability to utilize swap space, this situation is unfamiliar to me as well.
There seems to be an undocumented issue with Clear Linux’s memory management, especially concerning swap.
Not sure if if help but my PC was having “hiccups” and I got around it by switching to Wayland.