You are not logged in.
Pages: 1
I had a desktop machine lock up on me, and trying to get it regoing has been problematic.
Most of my computers are set with vsyscall=emulate on the command line, and as near as I can tell the only reason to have that setting, is that some sources of BOINC jobs require it. At one time (2 years ago), there was a special setting for BOINC having to do with LIBC215. I just went looking at Einstein @ Home, and no option like that appears to be present now.
In order to boot consistently now, I have had to remove execute permissions on /etc/init.d/boinc-client. If I boot to multiuser mode, and check the kernel command line, I can see the vsyscall=emulate. If I then restart BOINC, the system immediately locks up.
I had updated the system to the new libc (2.29-2) a few days ago. It may be that it took BOINC a few days to "tickle" something, which is causing this crashing.
Is there any way to get more information as to what is happening?
Offline
sysdig.com has an article on troubleshooting containers. I believe this story has something to do with vsyscall later on in the document.
https://sysdig.com/blog/troubleshooting-containers/
But, an early troubleshooting step shown here, is to generate a core dump.
ulimit -c unlimited
bad_command_to_execute
For me, this is some kind of BOINC process. It might be that executing the shell script in init.d might show something interesting, but I suppose the core produced would be of bash, dash or something like that. So, I think I need to manually start a BOINC job, in the hopes that it makes this vsyscall?
Offline
/proc/sys/debug/exception-trace has something to do with controlling verbosity (following that sysdig article). It can hold a 0 (off) or 1 (on). On my machine, it seems to be turned on already.
Offline
Pages: 1