4 ms·

Thank heavens for this advancement! I imagine those using Doom to manage system processes (https://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html https://www.cs

Thank heavens for this advancement! I imagine those using Doom to manage system processes (https://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html https://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html), will appreciate the security measures implemented in this version. I can only hope these two projects can find common purpose.

sjsbsh 9y ago
They’ll certainly have enough time to decide which proc to kill!
jghn 9y ago
Several years back I convinced a coworker to try and install that. He had a mac and I was running FreeBSD or something and couldn't run it. He'd been running some sort of simulation for several days on that machine. So we fired it up and within about 2-3 minutes he managed to shoot PID 1 or something like that as the machine rebooted. Boss was not happy.
- planteen 9y ago
  Haha that made me LOL
- rootw0rm 9y ago
  wtf, hahaha
- int0x80 9y ago
  mm usually PID 1 is unkillable even by root AFAIK.
  - gerdesj 9y ago
    Don't know why you got DVd. This does nothing on a VM running Kali Linux (systemd): # kill -9 1
    - abofh 9y ago
      https://www.freedesktop.org/software/systemd/man/systemd.html https://www.freedesktop.org/software/systemd/man/systemd.htm... - See signals It's init dependent (though I think SIGKILL is blocked at the kernel – I wouldn't swear to it) - sigrtmin+3 will likely kill your init process :)
      - gerdesj 9y ago
        Cor, the locals are a bit harsh here. I've just run # kill -L - there seem to me rather more signals available than I remember from the past. I'm pretty sure I have never even heard of the ones >16 let alone SIGRT{MIN|MAX}{|x}. I've only ever used SIGHUP or SIGKILL in general and SIGUSR1 for dd progress (which now has --progress at last) Time to dig out the manual 8)
      - int0x80 9y ago
        In Linux, from the manpage: "The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally." And SIGKILL can not be captured (enforced by the kernel): "The signals SIGKILL and SIGSTOP cannot be caught or ignored."
  - jghn 9y ago
    Actually you're right. He killed the simulation process now that I'm wracking my brain to remember how that actually worked. That then led to us joking about what it'd be like to force-reboot via the killing. The key detail I'll never forget is his "Oh fuck!" face when it happened.
    - abofh 9y ago
      https://www.freedesktop.org/software/systemd/man/systemd.html https://www.freedesktop.org/software/systemd/man/systemd.htm... Not all signals are blocked by init, if init wants to be signaled :)

sjsbsh 9y ago

They’ll certainly have enough time to decide which proc to kill!

jghn 9y ago

Several years back I convinced a coworker to try and install that. He had a mac and I was running FreeBSD or something and couldn't run it. He'd been running some sort of simulation for several days on that machine. So we fired it up and within about 2-3 minutes he managed to shoot PID 1 or something like that as the machine rebooted. Boss was not happy.

planteen 9y ago
Haha that made me LOL
rootw0rm 9y ago
wtf, hahaha
int0x80 9y ago
mm usually PID 1 is unkillable even by root AFAIK.
- gerdesj 9y ago
  Don't know why you got DVd. This does nothing on a VM running Kali Linux (systemd): # kill -9 1
  - abofh 9y ago
    https://www.freedesktop.org/software/systemd/man/systemd.html https://www.freedesktop.org/software/systemd/man/systemd.htm... - See signals It's init dependent (though I think SIGKILL is blocked at the kernel – I wouldn't swear to it) - sigrtmin+3 will likely kill your init process :)
    - gerdesj 9y ago
      Cor, the locals are a bit harsh here. I've just run # kill -L - there seem to me rather more signals available than I remember from the past. I'm pretty sure I have never even heard of the ones >16 let alone SIGRT{MIN|MAX}{|x}. I've only ever used SIGHUP or SIGKILL in general and SIGUSR1 for dd progress (which now has --progress at last) Time to dig out the manual 8)
    - int0x80 9y ago
      In Linux, from the manpage: "The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally." And SIGKILL can not be captured (enforced by the kernel): "The signals SIGKILL and SIGSTOP cannot be caught or ignored."
- jghn 9y ago
  Actually you're right. He killed the simulation process now that I'm wracking my brain to remember how that actually worked. That then led to us joking about what it'd be like to force-reboot via the killing. The key detail I'll never forget is his "Oh fuck!" face when it happened.
  - abofh 9y ago
    https://www.freedesktop.org/software/systemd/man/systemd.html https://www.freedesktop.org/software/systemd/man/systemd.htm... Not all signals are blocked by init, if init wants to be signaled :)