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?
]]>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?
]]>