Re: [Lxc-users] LXC on Debian Squeeze
Daniel Lezcano daniel.lezc...@free.fr writes:
On 09/28/2010 09:21 AM, Frank Bauer wrote:
On Mon, Sep 27, 2010 at 10:13 PM, Daniel Lezcanodaniel.lezc...@free.fr
wrote:
Maybe it would be easier to check first if you have this fd in bash with ls
-al /proc/pid/fd and then follow up the hierarchy to find the first
process who introduced this fd.
So, tracing the two open fds as you suggested
lxc-start: inherited fd 7 on pipe:[5329]
lxc-start: inherited fd 9 on pipe:[5333]
in the following tree
init─┬─acpid
├─console-kit-dae───63*[{console-kit-da}]
├─cron
├─2*[dbus-daemon]
├─dbus-launch
├─dhclient
├─gdm───gdm─┬─Xorg
│ └─fluxbox─┬─ssh-agent
│ ├─urxvt───bash───su───bash
│ └─xterm───bash───su───bash───pstree
revealed they are both open starting with the second gdm process
down to the leaf bash processes.
The first gdm process had only fd 7 on pipe:[5329] open and finally
init had none of these pipes.
As you can see, I have exchanged xmonad for fluxbox and in
addition to urxvt I tried xterm without any change.
To send the bugreport to a proper place, which process should be
responsible for closing those fds? gdm?
Yes, I think so.
I found that :
http://www.mail-archive.com/debian-bugs-clo...@lists.debian.org/msg270073.html
It was not considered as a bug but IMO it was not looked closely enough,
having a fd inherited in all the child processes is a bug :)
Maybe you can reopen it.
I couldn't agree more, please reopen the bug. I don't get why this
doesn't look like an actual leak.
--
Thanks,
Feri.
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] LXC on Debian Squeeze
Frank Bauer frank.c.ba...@gmail.com writes: squeeze:~# lxc-start -n container lxc-start: inherited fd 7 on pipe:[4220] lxc-start: inherited fd 9 on pipe:[4224] You can get your shell to close those file descriptors by # lxc-start -n 7- 8- But best would be to find out who leaked those, and fix the real breakage. Btw. lxc works for me on squeeze, but I use application containers only. -- Regards, Feri. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] unstoppable container
Serge E. Hallyn serge.hal...@canonical.com writes: Quoting Ferenc Wagner (wf...@niif.hu): Serge E. Hallyn serge.hal...@canonical.com writes: Quoting Daniel Lezcano (daniel.lezc...@free.fr): On 08/31/2010 12:23 AM, Serge E. Hallyn wrote: Quoting Daniel Lezcano (daniel.lezc...@free.fr): http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=13aa9a6b0f2371d2ce0de57c2ede62ab7a787157 http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=dd34200adc01c5217ef09b55905b5c2312d65535 http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=614c517d7c00af1b26ded20646b329397d6f51a1 Are they small enough for a SRU ? The first one looks trivial enough. I'd be afraid the second one would be considered to have deep and subtle regression potential. But, we can always try. I'm not on the kernel team so am not likely to have any say on it myself :) Shall we ask directly to the kernel-team@ mailing list? Or do we have to do a SRU first ? Actually, first step would be for Papp to open a bug against both lxc and the kernel. Papp, do you mind doing that? Without a bug, an SRU ain't gonna fly. I'm not sure what an SRU is, is that something Ubuntu-specific? I'd Yes, specific to Ubuntu LTS (long term support) releases. Thanks for the clarification. appreciate instead going through sta...@kernel.org, so that everybody benefits from this backporting effort. TBH, looking at the commit messages, it might be tough to make the case for -stable. They sure make the patches sound fluffy. I can't judge whether these patches (however small) bear a considerable risk. They change a small thing in the deep, as I see it. And since the problem can be worked around in userspace Do you mean by hunting down the orphaned processes based on the cgroup tasks files? I'm not sure the following rule: - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some oh, that's not good issue. In short, something critical. from Documentation/stable_kernel_rules.txt is satisfied. Well, I really don't know. Leaving stray processes in a container sounds bad to me, but maybe not exactly critical... I haven't got much experience with -stable. But if you all prefer to try that route first I'll certainly not object. It'd certainly help to present a concise and to-the-point summary why we need this in -stable. If you feel this is hopeless, then forget it, otherwise I'd very much appreciate your help on this issue. -- Thanks, Feri. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Storage with lxc
Yanick Emiliano lak...@gmail.com writes: I would like know if lxc at this stage suppots centralization network storage. I mean a Storage Filer , iSCSI, or *AoE storage*,For example can I have all my rootfs on a network filer and start each VM on a specific device storage on a network. If I understand you correctly, this is out of scope for lxc: it isn't concerned with the transport, it uses files and directories only. -- Regards, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] help with root mount parameters
atp andrew.phill...@lmax.com writes:
[r...@islab01 lxc]# lxc-start -n test01.dev.tradefair/
lxc-start: No such file or directory - failed to access to
'/usr/lib64/lxc', check it is present
This directory should be created by make install, but it isn't yet.
I don't have a lxc.rootfs.mount option in my config file,
so /usr/lib64/lxc seems to be the default (although confusingly
LXCROOTFSMOUNT is /usr/local/lib/lxc).
I'd submit a patch for that myself if I could see through the autoconf
maze.
{ lxc.rootfs.mount, config_rootfs_mount },
{ lxc.rootfs, config_rootfs },
{ lxc.pivotdir, config_pivotdir },
This now gives us several ways of specifying a root directory.
No, they are for different purposes.
When setting up a container with a rootfs, lxc does a pivot_root(2)
syscall to remove the original (host) root from the container namespace.
pivot_root(rootfs, pivotdir) makes rootfs the new root, and at the same
time moves the old root onto pivotdir (under the new root), where it can
be umounted from later. So the above config requires
/var/lib/nfsroot/mnt to exist beforehand. (If pivotdir is not
specified, a temporary directory is created and used instead, which
generally works, unless rootfs is read only.)
Now the above pivot_root syscall works only if rootfs and pivotdir are
not on the current root filesystem instance, which may or may not be the
case in a given configuration. So lxc first recursively binds rootfs to
rootfs.mount (in the container namespace) and pivots into that to ensure
that the above requirement is always satisfied.
--
HTH,
Feri.
--
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-unshare woes and signal forwarding in lxc-start
Daniel Lezcano daniel.lezc...@free.fr writes: On 05/13/2010 02:22 PM, Ferenc Wagner wrote: I attached a proof-of-concept patch which seems to work good enough for me. The function names are somewhat off now, but I leave that for later do you have definitive version for this ? I have some modifications in the start function and they may conflict with your patch. No, I didn't work on this any further. I'm not sure about the realtime signals... maybe it would be best to reverse the logic and use sigfillset and sigdelset instead? -- Cheers, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Actually, I'm not sure you can fully solve this. If rootfs is a separate file system, this is only much ado about nothing. If rootfs isn't a separate filesystem, you can't automatically find a good place and also clean it up. Maybe a single /tmp/lxc directory may be used as the mount points are private to the container. So it would be acceptable to have a single directory for N containers, no ? Then why not /usr/lib/lxc/pivotdir or something like that? Such a directory could belong to the lxc package and not clutter up /tmp. As you pointed out, this directory would always be empty in the outer name space, so a single one would suffice. Thus there would be no need cleaning it up, either. Agree. Shall we consider $(prefix)/var/run/lxc ? Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot if /var/run is on tmpfs. This isn't variable data either, that's why I recommended /usr above. Good point. I will change that to /usr/$(libdir)/lxc and let the distro maintainer to choose a better place if he wants with the configure option. I'm not sure what libdir is, doesn't this conflict with lxc-init? That's in the /usr/lib/lxc directory, at least in Debian. I'd vote for /usr/lib/lxc/oldroot in this setting. -- Regards, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Michael H. Warfield m...@wittsend.com writes:
On Wed, 2010-05-12 at 23:18 +0200, Daniel Lezcano wrote:
Ferenc Wagner wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Ferenc Wagner wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Ferenc Wagner wrote:
Actually, I'm not sure you can fully solve this. If rootfs is a
separate file system, this is only much ado about nothing. If rootfs
isn't a separate filesystem, you can't automatically find a good
place and also clean it up.
Maybe a single /tmp/lxc directory may be used as the mount points are
private to the container. So it would be acceptable to have a single
directory for N containers, no ?
Then why not /usr/lib/lxc/pivotdir or something like that? Such a
directory could belong to the lxc package and not clutter up /tmp. As
you pointed out, this directory would always be empty in the outer name
space, so a single one would suffice. Thus there would be no need
cleaning it up, either.
Agree. Shall we consider $(prefix)/var/run/lxc ?
Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot
if /var/run is on tmpfs. This isn't variable data either, that's why I
recommended /usr above.
Good point. I will change that to /usr/$(libdir)/lxc and let the distro
maintainer to choose a better place if he wants with the configure option.
Are you SURE you want /usr/${libdir}/lxc for this? Some high security
systems might mount /usr as a separate read-only partition (OK - I'm and
old school old fart). Part of the standard allows for /usr to be an RO
file system.
Read-only /usr is a good thing, and stays perfectly possible with this
choice. We're talking about an absolutely static directory, which
serves as a temporary mount point only.
Wouldn't this be more appropriate in /var/${libdir}/lxc instead? Maybe
create a .tmp directory under it or .tmp.${CTID} or something? Or,
maybe, something under /var/${libdir}/lxc/${CTID}/tmp instead? /var is
for things that change and vary. Wouldn't that be a better location and
you've already got control of the /var/${libdir}/lxc location, don't
you?
There's nothing variable in this directory, and we need a single one
only, and only when rootfs is the same file system as the current root
(looking forward a little bit).
I don't know the FHS by heart, maybe it has something to say about this.
I'd certainly be fine with /var/lib/lxc/oldroot or something like that
as well.
--
Regards,
Feri.
--
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-unshare woes and signal forwarding in lxc-start
Daniel Lezcano daniel.lezc...@free.fr writes:
Ferenc Wagner wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Ferenc Wagner wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Ferenc Wagner wrote:
I'd like to use lxc-start as a wrapper, invisible to the parent and
the (jailed) child. Of course I could hack around this by not
exec-ing lxc-start but keeping the shell around, trap all signals and
lxc-killing them forward. But it's kind of ugly in my opinion.
Ok, got it. I think that makes sense to forward the signals,
especially for job management. What signals do you want to
forward?
Basically all of them. I couldn't find a definitive list of signals
used for job control in SGE, but the following is probably a good
approximation: SIGTTOU, SIGTTIN, SIGUSR1, SIGUSR2, SIGCONT, SIGWINCH and
SIGTSTP.
Yes, that could be a good starting point. I was wondering about
SIGSTOP being sent to lxc-start which is not forwardable of course,
is it a problem ?
I suppose not, SIGSTOP and SIGKILL are impossible to use in application-
specific ways. On the other hand, SIGXCPU and SIGXFSZ should probably
be forwarded, too. Naturally, this business can't be perfected, but a
good enough solution could still be valuable.
Agree.
I attached a proof-of-concept patch which seems to work good enough for
me. The function names are somewhat off now, but I leave that for later.
Looking at the source, the SIGCHLD mechanism could be
mimicked, but LXC_TTY_ADD_HANDLER may get in the way.
We should remove LXC_TTY_ADD_HANDLER and do everything in the signal
handler of SIGCHLD by extending the handler. I have a pending fix
changing a bit the signal handler function.
What's the purpose of LXC_TTY_ADD_HANDLER anyway? I didn't dig into it.
I'm also worried about signals sent to the whole process group: they
may be impossible to distinguish from the targeted signals and thus
can't propagate correctly.
Good point. Maybe we can setpgrp the first process of the container?
We've got three options:
A) do nothing, as now
B) forward to our child
C) forward to our child's process group
The signal could arrive because it was sent to
1) the PID of lxc-start
2) the process group of lxc-start
If we don't put the first process of the container into a new process
group (as now), this is what happens:
AB C
1 swallowedOKothers also killed
2 OK child gets extraeverybody gets extra
If we put the first process of the container into a new process group:
AB C
1 swallowedOKothers also killed
2 swallowed only the child killed OK
Neither is a clear winner, although the latter is somewhat more
symmetrical. I'm not sure about wanting all this configurable...
hmm ... Maybe Greg, (it's an expert with signals and processes), has
an idea on how to deal with that.
I'd say we should setpgrp the container init, forward all signals we
can to it, and have a configuration option for the set of signals which
should be forwarded to the full process group of the container init.
Or does it make sense to swallow anything?
--
Cheers,
Feri.
From 8ba413c1c19cf188d1d1bf1ed72fe26f265c192b Mon Sep 17 00:00:00 2001
From: Ferenc Wagner wf...@niif.hu
Date: Thu, 13 May 2010 11:33:59 +0200
Subject: [PATCH] forward control signals to the container init
Signed-off-by: Ferenc Wagner wf...@niif.hu
---
src/lxc/start.c | 43 ++-
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/src/lxc/start.c b/src/lxc/start.c
index 7e34cce..58b747f 100644
--- a/src/lxc/start.c
+++ b/src/lxc/start.c
@@ -198,6 +198,16 @@ static int setup_sigchld_fd(sigset_t *oldmask)
return -1;
}
+ sigaddset(mask, SIGUSR1);
+ sigaddset(mask, SIGUSR2);
+ sigaddset(mask, SIGTERM);
+ sigaddset(mask, SIGCONT);
+ sigaddset(mask, SIGTSTP);
+ sigaddset(mask, SIGTTIN);
+ sigaddset(mask, SIGTTOU);
+ sigaddset(mask, SIGXCPU);
+ sigaddset(mask, SIGXFSZ);
+ sigaddset(mask, SIGWINCH);
if (sigaddset(mask, SIGCHLD) || sigprocmask(SIG_BLOCK, mask, oldmask)) {
SYSERROR(failed to set mask signal);
return -1;
@@ -238,22 +248,29 @@ static int sigchld_handler(int fd, void *data,
return -1;
}
- if (siginfo.ssi_code == CLD_STOPPED ||
- siginfo.ssi_code == CLD_CONTINUED) {
- INFO(container init process was stopped/continued);
- return 0;
- }
+ switch (siginfo.ssi_signo) {
+ case SIGCHLD:
+ if (siginfo.ssi_code == CLD_STOPPED ||
+ siginfo.ssi_code == CLD_CONTINUED) {
+ INFO(container init process was stopped/continued);
+ return 0;
+ }
- /* more robustness, protect ourself from a SIGCHLD sent
- * by a process different from the container init
- */
- if (siginfo.ssi_pid != *pid) {
- WARN(invalid pid for SIGCHLD);
+ /* more robustness, protect ourself from a SIGCHLD
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Actually, I'm not sure you can fully solve this. If rootfs is a separate file system, this is only much ado about nothing. If rootfs isn't a separate filesystem, you can't automatically find a good place and also clean it up. Maybe a single /tmp/lxc directory may be used as the mount points are private to the container. So it would be acceptable to have a single directory for N containers, no ? Then why not /usr/lib/lxc/pivotdir or something like that? Such a directory could belong to the lxc package and not clutter up /tmp. As you pointed out, this directory would always be empty in the outer name space, so a single one would suffice. Thus there would be no need cleaning it up, either. Agree. Shall we consider $(prefix)/var/run/lxc ? Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot if /var/run is on tmpfs. This isn't variable data either, that's why I recommended /usr above. Now the question is: if rootfs is a separate file system (which includes bind mounts), is the superfluous rbind of the original root worth skipping, or should we just do it to avoid needing an extra code path? Good question. IMO, skipping the rbind is ok for this case but it may be interesting from a coding point of view to have a single place identified for the rootfs (especially for mounting an image). I will cook a patchset to fix the rootfs location and then we can look at removing the superfluous rbind. I'm testing your patchset now. So far it seems to work as advertised. -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: We can't simply remove it because of the pivot_root which returns EBUSY. I suppose it's coming from: new_root and put_old must not be on the same file system as the current root. Hmm, this could indeed be a problem if lxc.rootfs is on the current root file system. I didn't consider pivoting to the same FS, but looks like this is the very reason for the current complexity in the architecture. Btw. is this really a safe thing to do, to pivot into a subdirectory of a file system? Is there really no way out of that? It seems pivot_root on the same fs works if an intermediate mount point is inserted between old_root and new_root but at the cost of having a lazy unmount when we unmount the old rootfs filesystems. After pivoting? Could you please illustrate this? I am looking at making possible to specify a rootfs which is a file system image or a block device. I am not sure this should be done by lxc but looking forward ... A device could be easily mounted by the user or by an lxc.mount.entry, so I don't think it needs special consideration. But as we will pivot_root right after, we won't reuse the real rootfs, so we can safely use the host /tmp. That will cause problems if rootfs is under /tmp, don't you think? Right :) Btw. my use case is exactly that: I mostly want to prune the namespace of the container, so I bind mount / to /tmp/.../jail and a couple of things (but not everything!) below that, and set rootfs=/tmp/.../jail. Actually, I'm not sure you can fully solve this. If rootfs is a separate file system, this is only much ado about nothing. If rootfs isn't a separate filesystem, you can't automatically find a good place and also clean it up. Maybe a single /tmp/lxc directory may be used as the mount points are private to the container. So it would be acceptable to have a single directory for N containers, no ? Then why not /usr/lib/lxc/pivotdir or something like that? Such a directory could belong to the lxc package and not clutter up /tmp. As you pointed out, this directory would always be empty in the outer name space, so a single one would suffice. Thus there would be no need cleaning it up, either. So why not require that rootfs is a separate filesystem, and let the user deal with it by doing the necessary bind mount in the lxc config? Hmm, that will break the actual user configurations. Yes, sadly. We can add a WARNING if rootfs is not a separate file system and provide the ability to let the user to do whatever he wants, IMO if it is well documented it is not a problem. Sure. It adds some complexity to the code, but lxc is there to help doing common tasks. Now the question is: if rootfs is a separate file system (which includes bind mounts), is the superfluous rbind of the original root worth skipping, or should we just do it to avoid needing an extra code path? -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-unshare woes and signal forwarding in lxc-start
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: I can see that lxc-unshare isn't for me: I wanted to use it to avoid adding the extra lxc-start process between two daemons communicating via signals, but it's impossible to unshare PID namespaces, so I'm doomed. There is a pending patchset to unshare the pid namespace, maybe for 2.6.35 or 2.6.36 ... Then why does lxc-unshare insist on forking? I thought unsharing the PID namespace was infeasible, because it changed the value returned by getpid(), but if more and more unsharing gets implemented, a PID-conserving helper would seem quite useful. Maybe not for virtualizing full systems, but very much for insulating batch jobs under the supervision of some scheduler (like SGE for example). -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-unshare woes and signal forwarding in lxc-start
Serge E. Hallyn se...@us.ibm.com writes: Quoting Daniel Lezcano (daniel.lezc...@free.fr): Serge E. Hallyn wrote: Quoting Ferenc Wagner (wf...@niif.hu): Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: I can see that lxc-unshare isn't for me: I wanted to use it to avoid adding the extra lxc-start process between two daemons communicating via signals, but it's impossible to unshare PID namespaces, so I'm doomed. There is a pending patchset to unshare the pid namespace, maybe for 2.6.35 or 2.6.36 ... Then why does lxc-unshare insist on forking? I'm not sure what you mean - both the lxc version you mentioned, and the newest commit in my git tree, go through lxc_clone(), which uses clone, not fork. Ferenc is referring to the unshare pid namespace patchset of Eric. That's what I thought at first, but lxc-unshare insist on forking didn't sound like it. But ok. Sorry, I didn't make a distinction between fork and clone, my point was that lxc-unshare always creates a new process, which pretty much goes against the idea of unshare(), which is to unshare some namespace without creating a new process as opposed to what clone() does. At least this is how I understand it. Reading the referred patch to unshare the pid namespace revealed that it still requires a fork/clone, so it isn't what I'm after, which probably won't happen soon anyway, simply because real unsharing of the pid namespace is conceptually problematic. -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: While playing with lxc-start, I noticed that /tmp is infested by empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the original /tmp is not available anymore, so rmdir(tmpname) at the bottom of setup_rootfs can't achieve much. Why is this temporary name needed anyway? Is pivoting impossible without it? That was put in place with chroot, before pivot_root, so the distro's scripts can remount their '/' without failing. Now we have pivot_root, I suppose we can change that to something cleaner... Like simply nuking it? Shall I send a patch? -- Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-unshare woes and signal forwarding in lxc-start
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: I'd like to use lxc-start as a wrapper, invisible to the parent and the (jailed) child. Of course I could hack around this by not exec-ing lxc-start but keeping the shell around, trap all signals and lxc-killing them forward. But it's kind of ugly in my opinion. Ok, got it. I think that makes sense to forward the signals, especially for job management. What signals do you want to forward? Basically all of them. I couldn't find a definitive list of signals used for job control in SGE, but the following is probably a good approximation: SIGTTOU, SIGTTIN, SIGUSR1, SIGUSR2, SIGCONT, SIGWINCH and SIGTSTP. This is application specific, though, lxc-start shouldn't have this hard-coded. Looking at the source, the SIGCHLD mechanism could be mimicked, but LXC_TTY_ADD_HANDLER may get in the way. I'm also worried about signals sent to the whole process group: they may be impossible to distinguish from the targeted signals and thus can't propagate correctly. -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Daniel Lezcano dlezc...@fr.ibm.com writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: While playing with lxc-start, I noticed that /tmp is infested by empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the original /tmp is not available anymore, so rmdir(tmpname) at the bottom of setup_rootfs can't achieve much. Why is this temporary name needed anyway? Is pivoting impossible without it? That was put in place with chroot, before pivot_root, so the distro's scripts can remount their '/' without failing. Now we have pivot_root, I suppose we can change that to something cleaner... Like simply nuking it? Shall I send a patch? Sure, if we can kill it, I will be glad to take your patch :) I can't see any reason why lxc-start couldn't do without that temporary recursive bind mount of the original root. If neither do you, I'll patch it out and see if it still flies. -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wf...@niif.hu writes:
Daniel Lezcano dlezc...@fr.ibm.com writes:
Ferenc Wagner wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Ferenc Wagner wrote:
While playing with lxc-start, I noticed that /tmp is infested by
empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs
in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the
original /tmp is not available anymore, so rmdir(tmpname) at the
bottom of setup_rootfs can't achieve much. Why is this temporary
name needed anyway? Is pivoting impossible without it?
That was put in place with chroot, before pivot_root, so the distro's
scripts can remount their '/' without failing.
Now we have pivot_root, I suppose we can change that to something
cleaner...
Like simply nuking it? Shall I send a patch?
Sure, if we can kill it, I will be glad to take your patch :)
I can't see any reason why lxc-start couldn't do without that temporary
recursive bind mount of the original root. If neither do you, I'll
patch it out and see if it still flies.
For my purposes the patch below works fine. I only run applications,
though, not full systems, so wider testing is definitely needed.
Thanks,
Feri.
From 98b24c13f809f18ab8969fb4d84defe6f812b25c Mon Sep 17 00:00:00 2001
From: Ferenc Wagner wf...@niif.hu
Date: Thu, 6 May 2010 14:47:39 +0200
Subject: [PATCH] no need to use a temporary directory for pivoting
That was put in place before lxc-start started using pivot_root, so
the distro scripts can remount / without problems.
Signed-off-by: Ferenc Wagner wf...@niif.hu
---
src/lxc/conf.c | 28 +++-
1 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index b27a11d..4379a32 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -588,37 +588,15 @@ static int setup_rootfs_pivot_root(const char *rootfs,
const char *pivotdir)
static int setup_rootfs(const char *rootfs, const char *pivotdir)
{
- char *tmpname;
- int ret = -1;
-
if (!rootfs)
return 0;
- tmpname = tempnam(/tmp, lxc-rootfs);
- if (!tmpname) {
- SYSERROR(failed to generate temporary name);
- return -1;
- }
-
- if (mkdir(tmpname, 0700)) {
- SYSERROR(failed to create temporary directory '%s', tmpname);
- return -1;
- }
-
- if (mount(rootfs, tmpname, none, MS_BIND|MS_REC, NULL)) {
- SYSERROR(failed to mount '%s'-'%s', rootfs, tmpname);
- goto out;
- }
-
- if (setup_rootfs_pivot_root(tmpname, pivotdir)) {
+ if (setup_rootfs_pivot_root(rootfs, pivotdir)) {
ERROR(failed to pivot_root to '%s', rootfs);
- goto out;
+ return -1;
}
- ret = 0;
-out:
- rmdir(tmpname);
- return ret;
+ return 0;
}
static int setup_pts(int pts)
--
1.6.5
--
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] lxc-unshare woes and signal forwarding in lxc-start
Hi,
as of git 305bc646, the following happens:
# strace -f lxc-unshare -s NETWORK
[...]
clone(Process 3085 attached (waiting for parent)
Process 3085 resumed (parent 3084 ready)
child_stack=0xbfe836d4, flags=0x4000|SIGCHLD) = 3085
[pid 3085] getpid()= 3085
[pid 3085] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 3085 detached
waitpid(3085, [{WIFSIGNALED(s) WTERMSIG(s) == SIGSEGV}], 0) = 3085
--- SIGCHLD (Child exited) @ 0 (0) ---
exit_group(11) = ?
On the other hand, 'lxc-unshare -s NETWORK -- ifconfig -a' works all
right. If I read the history correctly, lxc-unshare now always forks,
but the argument checking didn't follow this, so execvp fails when
args=NULL. The usage notes should also be changed to reflect this, and
the -f switch is past as well. Ored list of flags isn't particularly
clear, btw, and also a little cumbersome to use on the command line.
Why not do away with all the complexity of expression and parsing and
enable repeated -s options? Okay, it's a testing tool, but still... :)
I can see that lxc-unshare isn't for me: I wanted to use it to avoid
adding the extra lxc-start process between two daemons communicating via
signals, but it's impossible to unshare PID namespaces, so I'm doomed.
But now I see that signal forwarding was just added to lxc-init, would
you consider something like that in lxc-start as well?
--
Thanks,
Feri.
Ps: On a purely cosmetic account, it seems to me that struct start_arg
consists of pointers for no good reason.
--
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
