"Brian May" <[email protected]> wrote. > Sometimes a daemon will hang badly, and the init.d script won't kill it, > and killing one process leaves the other processes running. So you have to > go in by hand and kill -9 every process.
Under FreeBSD I have a service in a jail and run /etc/rc.d/jail stop <jailname> It kills all processes in the jail using "jail -r". While I find "cgcreate" and "cgexec" I cannot find the "destroyer" but I am sure there is one. "http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign"; "Systemd and cgroup developers are working together to turn systemd into a global cgroup manager that creates higher-level control knobs and prevents direct access to the kernel." FreeBSD is using rctl for resource control (not for jails only), and devfs.rules for access to devices (if needed). The standard rules for a jail have a handful of devices only "unhidden" (dev/stdin,stdout,zero, null etc.) It all goes down into a few well-defined areas of the kernel and the same controls exist inside and outside a jail. A handful of sysctls are added to define security of a jail further. From above: "What’s the Issue?" The problem is that cgroups were often built independently of the developers most familiar with the kernel subsystems they interact with. “This is partly because cgroup tends to add complexity and overhead to the existing subsystems and building and bolting something on the side is often the path of the least resistance,” said Tejun Heo, Linux kernel cgroup subsystem maintainer. “Combined with the fact that cgroup has been exploring new areas without firm established examples to follow, this led to some questionable design choices and relatively high level of inconsistency.” --- No, you are not allowed to look at FreeBSD's jail design;-) --- Cgroup is made of two parts: the cgroup core creates a hierarchical classification of processes running on the system, while a set of 13 controllers link the core with the kernel subsystems. The memory controller, for example, limits the amount of memory a group of processes can allocate from the system, the block controller can limit the bandwidth to the disk input/output, and so on. Kernel developers are now working to fix these issues by implementing a single unified hierarchy in the cgroup core and improving consistency among the controllers. But because of the patchwork nature of the subsystem and the need to ensure backward compatibility, they won’t be able to completely stop this abuse. That’s where systemd, and any other control agents that may emerge, comes in. --- Shudder.. How safe can this design be? Instead of getting the design right first time (instead "bolting something on the side is often the path of the least resistance") you create a second part to tame a beast you unleashed before. All in all I do not trust a system like this. Regards Peter _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
