Home | News | Download | Packages | Forum | Wiki | Github

(solved)Void machine becomes unresponsive after period of in activity

(chris tyler) #1

hi I have recently took the plunge to learn more about linux and installed void to a headless server that I have been experimenting with. so far I have fallen in love with void. I have taken to digging through man pages and google to find solutions to my problems as was the point of jumping into the void. but this issue is above my skill level in linux.

my system runs perfect to complaints, but after an extended period of time it becomes unresponsive no ssh no samba. I restart system manually it comes back up and repeats. can some one help me to know where to even begin troubleshooting this issue?

I’m running musl x86_64.

(Masato the Empty) #2

If you’re going to troubleshoot headless with only network accessibility (no local console on either serial or vga) then you’re a bit limited. Your only source of information is likely to be whatever system logs get entered before and during the event.

Make sure you enable socklog, or install another syslog server and enable that, since most of the services you’re probably interested in would use syslog facilities by default rather than their own log files. (primary way of going through socklog logs would be svlogtail)

Things that are hard to tell without further investigation:

  • Could the network and network services be failing while the server itself is still running?
    If so, then you might find an error in the system logs related to failing services or network.
    If a kernel/driver error is taking out your network but allowing the system to keep running, that would probably show up in the logs. (svlogtail kernel would be your best bet there)
  • Could the system be totally frozen due to a kernel panic? Might be harder to tell. Something severe could possibly completely hang the system rather quickly, preventing its entry into the logs…

At any rate, if you’re only checking after the fact (after you reset the system) then logs are the best thing you have to go by without attaching a console…

EDIT: picked up a link to the wiki on this thread (specifics for enabling socklog)

(Doge) #3

Could be a kernel issue. If you’re using latest 4.13 kernel, then try 4.9 which is the current LTS kernel.

(chris tyler) #4

Makes sense I didn’t even know there was an LTS kernel. Could you point me the right way on downgrading kernel on void?

(Erin) #5
xbps-install linux4.9

The other kernels can be removed using xbps-remove and vkpurge.

(chris tyler) #6

Switched to LTS 24 hours running without issue. Is there anyway to suggest this be added to the FAQ page? seems like it would be relevant information. I mean as far as the LTS-kernel existing.

(chris tyler) #7

Yea I think kernel may have fixed it but only time will tell.
Gonna give socklog a go when I get some free time this weekend, thx for link.

No logging by default didn’t really pay attention to that till I needed it. But makes you take a step back and look at how much hand holding other distros do these days.



I had exactly the same issue with an headless Void musl on a Raspberry3 used as personal server.
Don’t find any solution, except switch to Void glibc, and since it works like a charm.
May be some musl issue…

(chris tyler) #9

Disabling vt-d may have done the trick


Do you use Virtualisation?
When I have AMD-Vi enabled in BIOS, I have to boot with iommu=pt to prevent softlocks and various errors in dmesg when running virtual machines or after using them.

(chris tyler) #11

no running any vm at the moment. Gonna test for a while and see if vt-d is the issue


No. It’s a hardware issue. I run musl with insane uptimes and in any case, his problem went away with kernel and/or BIOS alterations. These kinds of issues are exactly why Void handles kernels the way it does, to permit fallback. You don’t necessarily need to go all the way back to an LTS kernel but for a fixed server that may indeed be best.

My suggestion for debugging would not be logs, but a screen with a process activity monitor running.