61–70 of 76 posts
Sometimes I wonder if I'm on a list somewhere for frequent Google searches such as this one - "How to kill a parent with all the children"!
For instance, when I want to stop conky, all I do is run `killall conky` and kills all of its processes at once.
Another longer way to do such thing is to run `kill -9 $(pidof conky)` which kills all returned processes.
Earlier quoted context omitted.
Not sure to be honest. From the documentation: "Writing "FROZEN" to the state file will freeze all tasks in the cgroup". Even if not, it should still be sufficient once all tasks are frozen: If you then send SIGKILL to all processes in the group, no fork bomb or similar process kerfuffle will be able to avoid being killed once they get unfrozen.
Unfortunately in cgroupv1, the freezer cgroup could put the processes into an unkillable state while frozen. This is fixed in cgroupv2 (which very recently got freezer support) but distros have yet to switch wholesale to cgroupv2 due to lack of adoption outside systemd.
It covers everything that needs to be covered, but it also gets right to the point. Yet without being overly terse or dry.
And it explains everything clearly. So often the writer is good at understanding an idea but not conveying it. This lays it out where it's easy to pick up.
Earlier quoted context omitted.
Unfortunately in cgroupv1, the freezer cgroup could put the processes into an unkillable state while frozen. This is fixed in cgroupv2 (which very recently got freezer support) but distros have yet to switch wholesale to cgroupv2 due to lack of adoption outside systemd.
Is that really an issue though? Unkillable is fine so long as it immediately handles the kill -9 as soon as it's unfrozen without running any additional syscalls.
It depends what you need. If you don't care that the kill operation might not complete without unfreezing the cgroup, then you're right that it's not an issue. But if the signal was lost (assuming this can happen with SIGKILL), unfreezing means that the number of processes might not decrease over time and you'll have to retry several times. Yeah, it'd be hard to hit this race more than ~5 times in a row but it still makes userspace programs more complicated than they need to be.
I don’t quite get what the implications are. The author also doesn’t seem to talk about their solution for it in the context.
timeout 86400 ssh me@example.com
I was reading the man page for timeout, and it looks like you can throw some kill options, but I never needed them, so I never looked for them.
Earlier quoted context omitted.
It's in kernel v5.3, which is expected in September, so it might be in Ubuntu Eoan Ermine 19.10. (After all 5.0 got released in March and Ubuntu 19.04 ships with 5.0.)
Yeah, that's when you'll just start seeing the new kernel in the wild. Not when you'll stop seeing older kernels in the wild.
Earlier quoted context omitted.
re: WaitForMultipleObjects, finally something like that is likely coming to Linux: https://www.reddit.com/r/linux/comments/ck77gm/valve_propose... > It's a shame really. Well, yes, and of course, yet at the same time it's FOSS, so ... if someone really needed it, they should have proposed a patch. ¯\_(ツ)_/¯
> Well, yes, and of course, yet at the same time it's FOSS, so ... if someone really needed it, they should have proposed a patch. ¯\_(ツ)_/¯ It's a bit like doing I/O that doesn't throw your data away... just use O_DIRECT, bring your own I/O manager and page cache and scheduling and simply implement all the low-level compatibility stuff yourself if you need such a weird thing ¯\_(ツ)_/¯
Because general purpose filesystems and I/O susbsystems are just that, general purpose.
PostgreSQL regularly woes about the problems of the Linux I/O and fs APIs, but ... to my knowledge they did not do much else. (Other than working around the problems in userspace, and taking the performance hit.)
If you want I/O that doesn't throw you data away, use the perfectly fine buffered I/O on let's say XFS. Fast, safe, sane. If you need more juice, add NVMe, and/or MD-RAID / LVM. And eventually you need to scale out to multiple nodes anyway, and then the performance of the cluster consistency subsystem will be the weak point.
Bazel-watcher tries to accomplish this on Linux by using process group IDs. It works, if imperfectly sometimes. I ported this to Windows[1] using Job Objects. As usual, the Windows API was hell, and I made use of undocumented syscalls in order to make it work (though that part is partly Go’s fault: when you start a process, it immediately drops the thread handle on the floor. If you start a process suspended, that me…
ResumeThread is a well documented API. As is TerminateJobObject. The one thing I find a bit baroque is the recently added way to make sure a process is in a job on creation, which I believe is part is the ProcThreadAttributes mechanism.