On Fri, Feb 22, 2013 at 2:50 PM, Guido Jäkel <g.jae...@dnb.de> wrote: > > Dear Ian, > > to support your request in a convenience way, i recently drop in a small > patch for the lxc-ps helper command. Using the LXC-aware frontend for ps, > you're able to filter the ps output down to a (set of) named container or all > of them. With the patch applied, you're now able to filter it down to the > oposite: The processes not in any container ns, i.e. that of the host. > > Notice that LXC is a "meta project" which is bundling the work of many other > to a vehicle know as container. To make commands offered by other packages > LXC-aware, we have to advance this request to the maintainers of this tools. > But this only make sense, if the feature have reached a "stable" state in the > context of LXC. > > In the mean time, the LXC project have to provide some helpers like lxc-ps. > And if you have a real usecase of it, then one have to build a lxc-killall. > > > A meta answer to your example is that the best practice for a realworld LXC > production setup will include not to run *any* service on the host. From > that, there's nothing that you can kill from the host inside a container "by > mistake". And even at all: Unix is Unix; the root user of the host is the > responsible super root user of the containers by basic design. And the root > have to be able to do anything with the system and subsystems without any > limitations as he may "kill -9 1" or "rm -r /". > > > with greetings > > Guido
Hi Guido - Thanks for the response on this and sorry for the delayed reply. I'm interested in this patch you have for lxc-ps. if ever I would just include your patches in my internal packages in order to get the same output as openvz's behavior. I've been looking for consistent transition from openvz to lxc and this is one step towards that direction. OpenVZ's vzctl for mainline is another. Soon we can have containers that run more or less identical inside LXC and OpenVZ (at least for our own uses). Ian > > On 2013-02-20 15:48, Serge Hallyn wrote: >> No. However, you should be able to hack it up pretty easily in >> userspace by comparing /proc/$$/ns/pid. It requires privilege, >> but a very simple, easy-to-verify helper which simply takes one >> argument and returns 0 if /proc/$1/ns/pid is the same as >> /proc/self/ns/pid should be trustable with setuid-root or >> file capabilities. >> >> -serge >> >> Quoting ian sison (mailing list) (ian.si...@gmail.com): >>> Hi - i'm re forwarding this email from 2011 in the hope that there's >>> been some work done on the mainline LXC code regarding hiding >>> container processes from the hardware node's process list. Back then >>> there was no option available in LXC to implement this. How about >>> today? >>> >>> - Ian >>> >>> >>> ---------- Forwarded message ---------- >>> From: ian sison (mailing list) <ian.si...@gmail.com> >>> Date: Tue, May 3, 2011 at 6:53 PM >>> Subject: Hiding container processes from Host/HN's 'ps' >>> To: lxc-users@lists.sourceforge.net >>> >>> >>> Hi all - >>> >>> In openvz, a certain sysctl parameter, >>> >>> kernel.pid_ns_hide_child = 1 >>> >>> when executed at HN system startup will hide any processes that run >>> inside the running containers from appearing in the output of 'ps'. >>> This makes for a cleaner 'ps' output in the hardware node, and >>> prevents inadvertent container malfunctions when something like >>> 'killall -9 httpd' is executed in the command line of the HN. >>> >>> How can i do the same with LXC? My google searches draw up a blank. >>> >>> - Ian > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
