Re: [Lxc-users] Container shutdown remounts the lxc partition read-only... again
Quoting Leonid Isaev (lis...@umail.iu.edu):
On Fri, 21 Jun 2013 09:27:44 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Leonid Isaev (lis...@umail.iu.edu):
Hi,
I have recently installed vanilla lxc-0.9.0 under archlinux and
encountered the old fs is remounted ro issue which is supposed to be
fixed since https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/942325 ...
The (also archlinux) containers' rootfs are located on a separate
partition mounted at /var/lib/lxc
--
$ mount | grep lxc
/dev/sda3 on /var/lib/lxc type ext4(rw,nosuid,nodev,relatime,data=ordered)
--
The rootfs.hold file is open, according to strace run against lxc-start,
e.g.: --
$ grep hold /var/log/lxc.strace.log
open(/var/lib/lxc/arch-LXC-test/rootfs.hold, O_RDWR|O_CREAT, 0600) = 13
--
Nevertheless, whenever I shutdown the container via lxc-stop,
the /var/lib/lxc partition is marked ro... What can I do to determine
what's going wrong?
what fs type are you using for /var/lib/lxc?
Just an ext4.
I just tried on ubuntu precise (3.2.0-48-generic) with daily ppa lxc
(0.9.0.0~staging~20130619-1813-0ubuntu1~ppa1~precise1), created a new
ext4 lv, mounted it at /var/lib/lxc2, and created a container there.
Started it, logged in and powered off; started it, lxc-stop'ped it.
Switched its profile to unconfined, started and stopped it. But the
fs stayed mounted rw.
I'd try: create a loopback fs with that fstype, mount it under /mnt2,
then run:
#include stdio.h
#include stdlib.h
#include fcntl.h
cat holdopen.c EOF
int main(int argc, char *argv[]) {
FILE *f = fopen(argv[1], w);
fprintf(f, 1022\n);
fflush(f);
lockf(fileno(f), F_TLOCK, 0);
sleep(999);
}
EOF
make holdopen
./holdopen /mnt2/xxx
mount -o remount,ro /mnt2/xxx
and see if it succeeds.
Mount correctly fails saying the FS is busy... After looking at lxc source, I
am very confused because pin_rootfs() in src/conf.c seems to do almost same
thing. I've rebuilt lxc-0.9.0 locally instead of using the packaged one, but
still shutting down the container gives a read-only FS. Can it be related to
the fact that both host and guest run systemd?
No, I don't think so. I can't think of anything the init would be
doing to make this happen.
Kernel seems more likely.
Also, please note that
lxc-shutdown has no effect as systemd powers off on receiving SIGRTMIN+4 (this
is configured via lxc.stopsignal by the lxc-archlinux template, so lxc-stop
gracefully shuts down the container).
-serge
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container shutdown remounts the lxc partition read-only... again
Quoting Leonid Isaev (lis...@umail.iu.edu):
Hi,
I have recently installed vanilla lxc-0.9.0 under archlinux and
encountered the old fs is remounted ro issue which is supposed to be fixed
since https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/942325 ... The (also
archlinux) containers' rootfs are located on a separate partition mounted at
/var/lib/lxc
--
$ mount | grep lxc
/dev/sda3 on /var/lib/lxc type ext4(rw,nosuid,nodev,relatime,data=ordered)
--
The rootfs.hold file is open, according to strace run against lxc-start, e.g.:
--
$ grep hold /var/log/lxc.strace.log
open(/var/lib/lxc/arch-LXC-test/rootfs.hold, O_RDWR|O_CREAT, 0600) = 13
--
Nevertheless, whenever I shutdown the container via lxc-stop, the /var/lib/lxc
partition is marked ro... What can I do to determine what's going wrong?
what fs type are you using for /var/lib/lxc?
I'd try: create a loopback fs with that fstype, mount it under /mnt2,
then run:
#include stdio.h
#include stdlib.h
#include fcntl.h
cat holdopen.c EOF
int main(int argc, char *argv[]) {
FILE *f = fopen(argv[1], w);
fprintf(f, 1022\n);
fflush(f);
lockf(fileno(f), F_TLOCK, 0);
sleep(999);
}
EOF
make holdopen
./holdopen /mnt2/xxx
mount -o remount,ro /mnt2/xxx
and see if it succeeds.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container shutdown remounts the lxc partition read-only... again
On Fri, 21 Jun 2013 09:27:44 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Leonid Isaev (lis...@umail.iu.edu):
Hi,
I have recently installed vanilla lxc-0.9.0 under archlinux and
encountered the old fs is remounted ro issue which is supposed to be
fixed since https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/942325 ...
The (also archlinux) containers' rootfs are located on a separate
partition mounted at /var/lib/lxc
--
$ mount | grep lxc
/dev/sda3 on /var/lib/lxc type ext4(rw,nosuid,nodev,relatime,data=ordered)
--
The rootfs.hold file is open, according to strace run against lxc-start,
e.g.: --
$ grep hold /var/log/lxc.strace.log
open(/var/lib/lxc/arch-LXC-test/rootfs.hold, O_RDWR|O_CREAT, 0600) = 13
--
Nevertheless, whenever I shutdown the container via lxc-stop,
the /var/lib/lxc partition is marked ro... What can I do to determine
what's going wrong?
what fs type are you using for /var/lib/lxc?
Just an ext4.
I'd try: create a loopback fs with that fstype, mount it under /mnt2,
then run:
#include stdio.h
#include stdlib.h
#include fcntl.h
cat holdopen.c EOF
int main(int argc, char *argv[]) {
FILE *f = fopen(argv[1], w);
fprintf(f, 1022\n);
fflush(f);
lockf(fileno(f), F_TLOCK, 0);
sleep(999);
}
EOF
make holdopen
./holdopen /mnt2/xxx
mount -o remount,ro /mnt2/xxx
and see if it succeeds.
Mount correctly fails saying the FS is busy... After looking at lxc source, I
am very confused because pin_rootfs() in src/conf.c seems to do almost same
thing. I've rebuilt lxc-0.9.0 locally instead of using the packaged one, but
still shutting down the container gives a read-only FS. Can it be related to
the fact that both host and guest run systemd? Also, please note that
lxc-shutdown has no effect as systemd powers off on receiving SIGRTMIN+4 (this
is configured via lxc.stopsignal by the lxc-archlinux template, so lxc-stop
gracefully shuts down the container).
Thanks,
Leonid.
--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] Container shutdown remounts the lxc partition read-only... again
Hi, I have recently installed vanilla lxc-0.9.0 under archlinux and encountered the old fs is remounted ro issue which is supposed to be fixed since https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/942325 ... The (also archlinux) containers' rootfs are located on a separate partition mounted at /var/lib/lxc -- $ mount | grep lxc /dev/sda3 on /var/lib/lxc type ext4(rw,nosuid,nodev,relatime,data=ordered) -- The rootfs.hold file is open, according to strace run against lxc-start, e.g.: -- $ grep hold /var/log/lxc.strace.log open(/var/lib/lxc/arch-LXC-test/rootfs.hold, O_RDWR|O_CREAT, 0600) = 13 -- Nevertheless, whenever I shutdown the container via lxc-stop, the /var/lib/lxc partition is marked ro... What can I do to determine what's going wrong? Thanks, Leonid. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
On 03/19/2012 03:50 AM, Serge Hallyn wrote: Quoting Daniel Lezcano (daniel.lezc...@free.fr): On 03/19/2012 12:00 AM, Serge Hallyn wrote: Hi, Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down a container by sending it SIGPWR. I'm attaching two ways to do that. In-line is a patch which modifies lxc-stop to take optional -s and -t args - -s for shutdown (meaning send SIGPWR), and -t for a timeout, after sending SIGPWR, to hard-kill the container. That may make more sense to implement a lxc-reboot | lxc-shutdow Is there another signal that would make sense for lxc-reboot? Yes, SIGINT will make the init process to restart the services. I said lxc-reboot but that could be lxc-shutdown -r. script on top of on lxc-kill. IMHO, I don't think adding a timeout is a good idea because the shutdown process may take more than the timeout to stop the services and the container could be killed while the services are doing some cleanup or flush or whatever. If this option is present, people will tend to use it instead of investigating if a service is stuck, or working, or flushing. I would recommend to let the shutdown script to handle the timeout by themselves. By 'let the shutdown script to handle the timeout by themselves, you mean let the scripts calling lxc-shutdown handle the timeout? I meant the initrd scripts within the container to be fixed to properly shutdown (for example add timeout or optimize the stopping services). The init process will send SIGTERM to all the processes and then SIGKILL after awhile. I don't think that should be handled from outside. Some services are bogus because they don't care when they are stopped in the shutdown process because they expect to be killed. For example, the sshd service was automatically respawned after being killed by init at the shutdown time but that was only spotted with containers. leave lxc-shutdown to be as simple as 'lxc-kill -n $1 SIGPWR ? Yes, lxc-shutdown could be in this case very trivial (may be adding a couple of things like waiting for the container to stop before exiting in order to have a synchronous command). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
On 03/19/2012 02:45 AM, Fajar A. Nugraha wrote: On Mon, Mar 19, 2012 at 7:05 AM, Daniel Lezcanodaniel.lezc...@free.fr wrote: On 03/19/2012 12:00 AM, Serge Hallyn wrote: Hi, Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down a container by sending it SIGPWR. I'm attaching two ways to do that. In-line is a patch which modifies lxc-stop to take optional -s and -t args - -s for shutdown (meaning send SIGPWR), and -t for a timeout, after sending SIGPWR, to hard-kill the container. That may make more sense to implement a lxc-reboot | lxc-shutdow script on top of on lxc-kill. IMHO, I don't think adding a timeout is a good idea because the shutdown process may take more than the timeout to stop the services and the container could be killed while the services are doing some cleanup or flush or whatever. If this option is present, people will tend to use it instead of investigating if a service is stuck, or working, or flushing. I would recommend to let the shutdown script to handle the timeout by themselves. IIRC xen's xm shutdown command does something like this, which can be a starting design point: - check whether the container can handle a clean shutdown, by checking whether anything on the guest is listening on xenbus. If something is listening, then it's assumed the guest has PV drivers that can do clean shutdown. - if yes, issue clean shutdown command. The shutdown command returns immediately unless a -w is specified - if no, then it does xm destroy (i.e. force kill) The problem with lxc is that AFAIK there's nothing standard on the guest that can tell the host I can do clean shutdown, don't kill me! (the equivalent of xenbus listener check). I am not sure to understand what you mean by 'clean shutdown'. Can you elaborate ? Do you mean 'reboot' is supported by the kernel when not in the initial pid namespace ? Personally I like the timeout (so that the guest container will be shutdown in the end, no matter what). But then again the timeout can be ommited from lxc-shutdown if: - it's assumed the user knows what it's doing (i.e. they will manually force-kill the guest if needed) IMO, this is the correct approach. Note I am not saying a timeout is not necessary but I think that should not be implemented in lxc directly but in an upper script if it makes sense and that should be trivial with lxc-kill. - if clean shutdown will be the default action, there will be additional modification in init/upstart config that can force-kill guests after a timeout. Do you mean when the host is shutdown, the upstart scripts will shutdown all the containers ? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
On 3/19/2012 9:25 AM, Serge Hallyn wrote: Quoting Daniel Lezcano (daniel.lezc...@free.fr): On 03/19/2012 03:50 AM, Serge Hallyn wrote: Quoting Daniel Lezcano (daniel.lezc...@free.fr): On 03/19/2012 12:00 AM, Serge Hallyn wrote: Hi, Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down a container by sending it SIGPWR. I'm attaching two ways to do that. In-line is a patch which modifies lxc-stop to take optional -s and -t args - -s for shutdown (meaning send SIGPWR), and -t for a timeout, after sending SIGPWR, to hard-kill the container. That may make more sense to implement a lxc-reboot | lxc-shutdow Is there another signal that would make sense for lxc-reboot? Yes, SIGINT will make the init process to restart the services. I said lxc-reboot but that could be lxc-shutdown -r. I personally prefer lxc-reboot, but I can imagine people liking lxc-shutdown -r. What do others prefer? script on top of on lxc-kill. IMHO, I don't think adding a timeout is a good idea because the shutdown process may take more than the timeout to stop the services and the container could be killed while the services are doing some cleanup or flush or whatever. If this option is present, people will tend to use it instead of investigating if a service is stuck, or working, or flushing. I would recommend to let the shutdown script to handle the timeout by themselves. By 'let the shutdown script to handle the timeout by themselves, you mean let the scripts calling lxc-shutdown handle the timeout? I meant the initrd scripts within the container to be fixed to properly shutdown (for example add timeout or optimize the stopping services). The init process will send SIGTERM to all the processes and then SIGKILL after awhile. I don't think that should be handled from outside. I agree we want to do that where we can. I disagree that we should rely on it. Some services are bogus because they don't care when they are stopped in the shutdown process because they expect to be killed. For example, the sshd service was automatically respawned after being killed by init at the shutdown time but that was only spotted with containers. Right, and we should (and did) fix that, but lxc shouldn't look broken when the container misbehaves. leave lxc-shutdown to be as simple as 'lxc-kill -n $1 SIGPWR ? Yes, lxc-shutdown could be in this case very trivial (may be adding a couple of things like waiting for the container to stop before exiting in order to have a synchronous command). (I dunno, from there it seems to me the next logical step to add a timeout :) But just waiting is fine for me.) Ok, so lxc-kill -n $1 SIGPWR lxc-wait -n $1 STOPPED I'll wait for comments on lxc-reboot v lxc-shutdown -r. Timout: I can think of no excuse to omit a timeout option. It would be easy and it would be useful and it would be more admin-friendly than requiring the init script author to do it, or fail to do it, or do it poorly, or have 12 different distro's all do it differently, etc... Any that want to do it themselves, still can, since it's merely an option not a hard coded behavior. If you need to watch for something that _you_ know means it's ok to destroy, yet doesn't look like stopped to lxc-wait, no problem, just don't use that option. But by far the more usual and therefor should be the default behavior, would be don't allow a hung container to prevent the host from shutting down gracefully. That allows one bad container to possibly harm the host and thereby all other containers on that host. My own init script for suse has this problem. I know ways I could fix it but I've just been busy with other work so it just continues to have this problem for a year now... Executable name: I would prefer several almost identical actions to be implemented in one program with options instead of several almost identical programs. So I say lxc-shutdown -r than lxc-reboot. But I have no problem with lxc-shutdown doing -r based on argv0 as well as getopts. Everyone can have what they want without asking you the author to write multiple programs. -- bkw -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] container shutdown
Hi,
Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down
a container by sending it SIGPWR. I'm attaching two ways to do that.
In-line is a patch which modifies lxc-stop to take optional -s and -t
args - -s for shutdown (meaning send SIGPWR), and -t for a timeout,
after sending SIGPWR, to hard-kill the container.
Attached is a lxc-shutdown script (as an alternative) so lxc-stop can
continue to work as it has.
Both are in the bzr tree at
lp:~serge-hallyn/ubuntu/precise/lxc/lxc-shutdown, which builds and gives
you both.
What do we prefer?
thanks,
-serge
Signed-off-by: Serge Hallyn serge.hal...@canonical.com
---
doc/lxc-stop.sgml.in | 10 ++
src/lxc/arguments.h |4
src/lxc/commands.c |8
src/lxc/lxc.h|5 -
src/lxc/lxc_stop.c | 22 +++---
src/lxc/stop.c | 27 +--
6 files changed, 66 insertions(+), 10 deletions(-)
Index: lxc/doc/lxc-stop.sgml.in
===
--- lxc.orig/doc/lxc-stop.sgml.in 2012-03-18 16:33:06.254906000 -0500
+++ lxc/doc/lxc-stop.sgml.in2012-03-18 16:34:11.970538920 -0500
@@ -49,6 +49,7 @@
refsynopsisdiv
cmdsynopsis
commandlxc-stop replaceable-n name/replaceable
+ optional-s/optional optional-t timeout/optional
/command
/cmdsynopsis
/refsynopsisdiv
@@ -62,6 +63,15 @@
longer accessible and can no be exited normally.
/para
+para
+ If optional-s/optional (optional--shutdown/optional) is
+ specified, then ask the container to shut down cleanly by sending
+ a emphasisSIGPWR/emphasis signal. If optional-t timeout/optional
+ is also given, then emphasistimeout/emphasis seconds after sending
+ SIGPWR, if the container is still up, proceed to kill the container.
+ Note that optional-t timeout/optional implies
optional-s/optional.
+/para
+
/refsect1
commonoptions;
Index: lxc/src/lxc/arguments.h
===
--- lxc.orig/src/lxc/arguments.h2012-03-18 16:33:06.254906000 -0500
+++ lxc/src/lxc/arguments.h 2012-03-18 16:34:19.442575978 -0500
@@ -46,6 +46,10 @@
const char *rcfile;
const char *console;
+ /* for lxc-stop */
+ int timeout;
+ int shutdown;
+
/* for lxc-checkpoint/restart */
const char *statefile;
int statefd;
Index: lxc/src/lxc/commands.c
===
--- lxc.orig/src/lxc/commands.c 2012-03-18 16:33:06.254906000 -0500
+++ lxc/src/lxc/commands.c 2012-03-18 16:34:26.862612782 -0500
@@ -162,10 +162,10 @@
typedef int (*callback)(int, struct lxc_request *, struct lxc_handler
*);
callback cb[LXC_COMMAND_MAX] = {
- [LXC_COMMAND_TTY] = lxc_console_callback,
- [LXC_COMMAND_STOP] = lxc_stop_callback,
- [LXC_COMMAND_STATE] = lxc_state_callback,
- [LXC_COMMAND_PID] = lxc_pid_callback,
+ [LXC_COMMAND_TTY] = lxc_console_callback,
+ [LXC_COMMAND_STOP] = lxc_stop_callback,
+ [LXC_COMMAND_STATE] = lxc_state_callback,
+ [LXC_COMMAND_PID] = lxc_pid_callback,
};
if (request-type 0 || request-type = LXC_COMMAND_MAX)
Index: lxc/src/lxc/lxc_stop.c
===
--- lxc.orig/src/lxc/lxc_stop.c 2012-03-18 16:33:06.254906000 -0500
+++ lxc/src/lxc/lxc_stop.c 2012-03-18 17:24:47.137589512 -0500
@@ -30,7 +30,18 @@
#include arguments.h
+static int my_parser(struct lxc_arguments* args, int c, char* arg)
+{
+ switch (c) {
+ case 's': args-shutdown = 1; break;
+ case 't': args-timeout = arg; args-shutdown = 1; break;
+ }
+ return 0;
+}
+
static const struct option my_longopts[] = {
+ {shutdown, no_argument, 0, 's'},
+ {timeout, required_argument, 0, 't'},
LXC_COMMON_OPTIONS
};
@@ -42,10 +53,15 @@
lxc-stop stops a container with the identifier NAME\n\
\n\
Options :\n\
- -n, --name=NAME NAME for name of the container\n,
+ -n, --name=NAME NAME for name of the container\n\
+ -s, --shutdownAsk container to shut down cleanly\n\
+ -t, --timeout=t Imply -s and hard-kill container after t seconds\n\
+(default is -1, no timeout)\n,
.options = my_longopts,
- .parser = NULL,
+ .parser = my_parser,
.checker = NULL,
+ .timeout = -1,
+ .shutdown = 0,
};
int main(int argc, char *argv[])
@@ -57,5 +73,5 @@
my_args.progname, my_args.quiet))
return -1;
- return lxc_stop(my_args.name);
+ return lxc_stop(my_args.name, my_args.shutdown, my_args.timeout);
}
Index: lxc/src/lxc/stop.c
===
Re: [Lxc-users] container shutdown
On 03/19/2012 12:00 AM, Serge Hallyn wrote:
Hi,
Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down
a container by sending it SIGPWR. I'm attaching two ways to do that.
In-line is a patch which modifies lxc-stop to take optional -s and -t
args - -s for shutdown (meaning send SIGPWR), and -t for a timeout,
after sending SIGPWR, to hard-kill the container.
That may make more sense to implement a lxc-reboot | lxc-shutdow script
on top of on lxc-kill.
IMHO, I don't think adding a timeout is a good idea because the shutdown
process may take more than the timeout to stop the services and the
container could be killed while the services are doing some cleanup or
flush or whatever. If this option is present, people will tend to use it
instead of investigating if a service is stuck, or working, or flushing.
I would recommend to let the shutdown script to handle the timeout by
themselves.
Attached is a lxc-shutdown script (as an alternative) so lxc-stop can
continue to work as it has.
Both are in the bzr tree at
lp:~serge-hallyn/ubuntu/precise/lxc/lxc-shutdown, which builds and gives
you both.
What do we prefer?
thanks,
-serge
Signed-off-by: Serge Hallynserge.hal...@canonical.com
---
doc/lxc-stop.sgml.in | 10 ++
src/lxc/arguments.h |4
src/lxc/commands.c |8
src/lxc/lxc.h|5 -
src/lxc/lxc_stop.c | 22 +++---
src/lxc/stop.c | 27 +--
6 files changed, 66 insertions(+), 10 deletions(-)
Index: lxc/doc/lxc-stop.sgml.in
===
--- lxc.orig/doc/lxc-stop.sgml.in 2012-03-18 16:33:06.254906000 -0500
+++ lxc/doc/lxc-stop.sgml.in 2012-03-18 16:34:11.970538920 -0500
@@ -49,6 +49,7 @@
refsynopsisdiv
cmdsynopsis
commandlxc-stopreplaceable-n name/replaceable
+optional-s/optional optional-t timeout/optional
/command
/cmdsynopsis
/refsynopsisdiv
@@ -62,6 +63,15 @@
longer accessible and can no be exited normally.
/para
+para
+ Ifoptional-s/optional (optional--shutdown/optional) is
+ specified, then ask the container to shut down cleanly by sending
+ aemphasisSIGPWR/emphasis signal. Ifoptional-t
timeout/optional
+ is also given, thenemphasistimeout/emphasis seconds after sending
+ SIGPWR, if the container is still up, proceed to kill the container.
+ Note thatoptional-t timeout/optional
impliesoptional-s/optional.
+/para
+
/refsect1
commonoptions;
Index: lxc/src/lxc/arguments.h
===
--- lxc.orig/src/lxc/arguments.h 2012-03-18 16:33:06.254906000 -0500
+++ lxc/src/lxc/arguments.h 2012-03-18 16:34:19.442575978 -0500
@@ -46,6 +46,10 @@
const char *rcfile;
const char *console;
+ /* for lxc-stop */
+ int timeout;
+ int shutdown;
+
/* for lxc-checkpoint/restart */
const char *statefile;
int statefd;
Index: lxc/src/lxc/commands.c
===
--- lxc.orig/src/lxc/commands.c 2012-03-18 16:33:06.254906000 -0500
+++ lxc/src/lxc/commands.c2012-03-18 16:34:26.862612782 -0500
@@ -162,10 +162,10 @@
typedef int (*callback)(int, struct lxc_request *, struct lxc_handler
*);
callback cb[LXC_COMMAND_MAX] = {
- [LXC_COMMAND_TTY] = lxc_console_callback,
- [LXC_COMMAND_STOP] = lxc_stop_callback,
- [LXC_COMMAND_STATE] = lxc_state_callback,
- [LXC_COMMAND_PID] = lxc_pid_callback,
+ [LXC_COMMAND_TTY] = lxc_console_callback,
+ [LXC_COMMAND_STOP] = lxc_stop_callback,
+ [LXC_COMMAND_STATE] = lxc_state_callback,
+ [LXC_COMMAND_PID] = lxc_pid_callback,
};
if (request-type 0 || request-type= LXC_COMMAND_MAX)
Index: lxc/src/lxc/lxc_stop.c
===
--- lxc.orig/src/lxc/lxc_stop.c 2012-03-18 16:33:06.254906000 -0500
+++ lxc/src/lxc/lxc_stop.c2012-03-18 17:24:47.137589512 -0500
@@ -30,7 +30,18 @@
#include arguments.h
+static int my_parser(struct lxc_arguments* args, int c, char* arg)
+{
+ switch (c) {
+ case 's': args-shutdown = 1; break;
+ case 't': args-timeout = arg; args-shutdown = 1; break;
+ }
+ return 0;
+}
+
static const struct option my_longopts[] = {
+ {shutdown, no_argument, 0, 's'},
+ {timeout, required_argument, 0, 't'},
LXC_COMMON_OPTIONS
};
@@ -42,10 +53,15 @@
lxc-stop stops a container with the identifier NAME\n\
\n\
Options :\n\
- -n, --name=NAME NAME for name of the container\n,
+ -n, --name=NAME NAME for name of the container\n\
+ -s, --shutdownAsk container to shut down cleanly\n\
+
Re: [Lxc-users] container shutdown
On Mon, Mar 19, 2012 at 7:05 AM, Daniel Lezcano daniel.lezc...@free.fr wrote: On 03/19/2012 12:00 AM, Serge Hallyn wrote: Hi, Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down a container by sending it SIGPWR. I'm attaching two ways to do that. In-line is a patch which modifies lxc-stop to take optional -s and -t args - -s for shutdown (meaning send SIGPWR), and -t for a timeout, after sending SIGPWR, to hard-kill the container. That may make more sense to implement a lxc-reboot | lxc-shutdow script on top of on lxc-kill. IMHO, I don't think adding a timeout is a good idea because the shutdown process may take more than the timeout to stop the services and the container could be killed while the services are doing some cleanup or flush or whatever. If this option is present, people will tend to use it instead of investigating if a service is stuck, or working, or flushing. I would recommend to let the shutdown script to handle the timeout by themselves. IIRC xen's xm shutdown command does something like this, which can be a starting design point: - check whether the container can handle a clean shutdown, by checking whether anything on the guest is listening on xenbus. If something is listening, then it's assumed the guest has PV drivers that can do clean shutdown. - if yes, issue clean shutdown command. The shutdown command returns immediately unless a -w is specified - if no, then it does xm destroy (i.e. force kill) The problem with lxc is that AFAIK there's nothing standard on the guest that can tell the host I can do clean shutdown, don't kill me! (the equivalent of xenbus listener check). Personally I like the timeout (so that the guest container will be shutdown in the end, no matter what). But then again the timeout can be ommited from lxc-shutdown if: - it's assumed the user knows what it's doing (i.e. they will manually force-kill the guest if needed) - if clean shutdown will be the default action, there will be additional modification in init/upstart config that can force-kill guests after a timeout. -- Fajar -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
Quoting Daniel Lezcano (daniel.lezc...@free.fr): On 03/19/2012 12:00 AM, Serge Hallyn wrote: Hi, Thanks to Jäkel's and Fajar's great ideas, we can now cleanly shut down a container by sending it SIGPWR. I'm attaching two ways to do that. In-line is a patch which modifies lxc-stop to take optional -s and -t args - -s for shutdown (meaning send SIGPWR), and -t for a timeout, after sending SIGPWR, to hard-kill the container. That may make more sense to implement a lxc-reboot | lxc-shutdow Is there another signal that would make sense for lxc-reboot? script on top of on lxc-kill. IMHO, I don't think adding a timeout is a good idea because the shutdown process may take more than the timeout to stop the services and the container could be killed while the services are doing some cleanup or flush or whatever. If this option is present, people will tend to use it instead of investigating if a service is stuck, or working, or flushing. I would recommend to let the shutdown script to handle the timeout by themselves. By 'let the shutdown script to handle the timeout by themselves, you mean let the scripts calling lxc-shutdown handle the timeout? And leave lxc-shutdown to be as simple as 'lxc-kill -n $1 SIGPWR ? thanks, -serge -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
On 06/01/2010 08:27 PM, atp wrote:
Ok,
absolutely the last post tonight. I promise.
I fixed the find /var/run -exec rm -f {} command in rc.sysinit.
Now the problem is that the runlevel is written whilst things are
still shutting down;
/lxc/test01.dev.tradefair/rootfs/var/run/utmp MODIFY
/lxc/test01.dev.tradefair/rootfs/var/run/utmp CLOSE_WRITE,CLOSE
/lxc/test01.dev.tradefair/rootfs/var/run/utmp OPEN
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp CLOSE_NOWRITE,CLOSE
lxc-start 1275416907.960 DEBUGlxc_utmp - utmp handler fired
lxc-start 1275416907.960 DEBUGlxc_utmp - run level is 3/0
lxc-start 1275416907.960 DEBUGlxc_utmp - there is 13 tasks
remaining
By the time I can cat /cgroup/machine name/tasks there's only one
left, but when the MODIFY fires there are still tasks shutting down.
Rather annoying after all that, looks like I'll have to find another
way.
Is it possible upstart respawns the services when they are killed ?
--
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] container shutdown
Hello, Been looking at getting this patch working; http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=commitdiff;h=563f2f2ccd2891661836c96f92f047a735355c1b;hp=3bdf52d753ecf347b3b5cbff97675032f2de3e5e This patch allows to shutdown the container when the system is powered off in the container. Short summary is I can't get it to work on FC12 host/FC12 container. I've moved the DEBUG(run level is %c/%c, prevrun_level, currun_level); DEBUG(there is %d tasks remaining, ntasks); outside of the if statement in utmp_handler So they print out everytime the handler is fired. On boot I get this: (-s lxc.console=DEBUG -o /tmp/trace.log) lxc-start 1275412479.567 NOTICE lxc_start - '/sbin/init' started with pid '23264' lxc-start 1275412479.567 DEBUGlxc_utmp - Added '/lxc/test01.dev.tradefair/rootfs/var/run/utmp' to inotifywatch lxc-start 1275412479.573 DEBUGlxc_cgroup - using cgroup mounted at '/cgroup' lxc-start 1275412479.573 DEBUGlxc_utmp - utmp handler fired lxc-start 1275412479.573 DEBUGlxc_utmp - run level is 6/S lxc-start 1275412479.573 DEBUGlxc_utmp - there is 2 tasks remaining lxc-start 1275412479.659 DEBUGlxc_utmp - utmp handler fired lxc-start 1275412479.660 DEBUGlxc_utmp - run level is N/N lxc-start 1275412479.660 DEBUGlxc_utmp - there is 5 tasks remaining So far so good. Now unfortunately, logging into the console as root, touch -m /var/run/utmp from within the container and without, or copying the utmp file to tmp and back over itself elicits no further response. halting or rebooting the container shows no sign the utmp handler is being fired correctly. I've checked timezones and clocks are set. I'm beginning to suspect that inotify is becoming disabled somehow. The second run shows N/N which means that its unable to parse the utmp file. Checking with dump_utmp seems to indicate that the file is not corrupt. Removing the utmp file and rebooting the container to regenerate it does not help. I've run out of ideas for now, but if anyone has any thoughts on this please let me know. Andy Andrew Phillips Head of Systems www.lmax.com Office: +44 203 1922509 Mobile: +44 (0)7595 242 900 LMAX | Level 2, Yellow Building | 1 Nicholas Road | London | W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
Bad idea to follow up on yourself, however I've got a bit further; running an inotifywait -m on the file at the same time as I'm tailing the log file gives you; lxc-start 1275415483.290 DEBUGlxc_cgroup - using cgroup mounted at '/cgroup' lxc-start 1275415483.290 DEBUGlxc_utmp - utmp handler fired lxc-start 1275415483.290 DEBUGlxc_utmp - run level is 0/S lxc-start 1275415483.290 DEBUGlxc_utmp - there is 2 tasks remaining /lxc/test01.dev.tradefair/rootfs/var/run/utmp CLOSE_NOWRITE,CLOSE /lxc/test01.dev.tradefair/rootfs/var/run/utmp ATTRIB /lxc/test01.dev.tradefair/rootfs/var/run/utmp DELETE_SELF /lxc/test01.dev.tradefair/rootfs/var/run/utmp IGNORED lxc-start 1275415483.377 DEBUGlxc_utmp - utmp handler fired lxc-start 1275415483.377 DEBUGlxc_utmp - run level is N/N lxc-start 1275415483.377 DEBUGlxc_utmp - there is 5 tasks remaining So that IGNORED in there means that during boot fedora is deleting and remaking the file. For now, preventing fedora from deleting it seems to be the way forward. Andy Andrew Phillips Head of Systems www.lmax.com Office: +44 203 1922509 Mobile: +44 (0)7595 242 900 LMAX | Level 2, Yellow Building | 1 Nicholas Road | London | W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] container shutdown
Ok,
absolutely the last post tonight. I promise.
I fixed the find /var/run -exec rm -f {} command in rc.sysinit.
Now the problem is that the runlevel is written whilst things are
still shutting down;
/lxc/test01.dev.tradefair/rootfs/var/run/utmp MODIFY
/lxc/test01.dev.tradefair/rootfs/var/run/utmp CLOSE_WRITE,CLOSE
/lxc/test01.dev.tradefair/rootfs/var/run/utmp OPEN
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp ACCESS
/lxc/test01.dev.tradefair/rootfs/var/run/utmp CLOSE_NOWRITE,CLOSE
lxc-start 1275416907.960 DEBUGlxc_utmp - utmp handler fired
lxc-start 1275416907.960 DEBUGlxc_utmp - run level is 3/0
lxc-start 1275416907.960 DEBUGlxc_utmp - there is 13 tasks
remaining
By the time I can cat /cgroup/machine name/tasks there's only one
left, but when the MODIFY fires there are still tasks shutting down.
Rather annoying after all that, looks like I'll have to find another
way.
Andy
Andrew Phillips
Head of Systems
www.lmax.com
Office: +44 203 1922509
Mobile: +44 (0)7595 242 900
LMAX | Level 2, Yellow Building | 1 Nicholas Road | London | W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way.
If you are not a named recipient please notify the sender immediately and
delete any copies of this message. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any view or
opinions presented are solely those of the author and do not necessarily
represent those of the company.
--
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
