This fixes a bug introduced by:
commit 94f0035bf6
Author: Christian Brauner <christian.brauner@ubuntu.com>
Date: Thu Dec 7 15:07:26 2017 +0100
coverity: #1425924
remove logically dead condition
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Coverity's bug analysis is correct but my fix wasn't.
This commit fixes a bunch of other bugs I just spotted as well.
This unblocks #2009.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
The same message exists in lxclock.c and cgmanager.c, so print the
filename along with the message.
Before this patch:
lxc-destroy -n u1
pthread_mutex_unlock returned:1 Operation not permitted
After this patch:
xc-destroy -n u1
lxclock.c: pthread_mutex_unlock returned:1 Operation not permitted
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Avoid NULL-pointer dereference. Apparently monitor.{c,h} calls
lxc_check_inherited() with NULL passed for the config. This isn't really a big
issue since monitor.{c,h} is effectively dead for all liblxc versions that have
the state client patch. Also, the patch that introduces the relevant lines into
lxc_check_inherited() is only in master and yet unreleased.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
lxc_init.c should not depend on tools/arguments.{c,h}, thus it needs its own custom argument parser
Signed-off-by: RicardoSanchezA <ricardo.sanchez@utexas.edu>
It doesn't make sense to error out when an app container doesn't pass explicit
arguments through c->start{l}(). This is especially true since we implemented
lxc.execute.cmd. However, even before we could have always relied on
lxc.init.cmd and errored out after that.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Callers can then make a decision whether they want to consider the peer closing
the connection an error or not. For example, a c->wait(c, "STOPPED", -1) call
can then consider a ECONNRESET not an error but rather see it - correctly - as
a container exiting before being able to register a state client.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Take the lock on the list after we've done all necessary work and check state.
If we are in requested state, do cleanup and return without adding the state
client to the state client list.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This adds reboot2() as a new API extension. This function properly wait until a
reboot succeeded. It takes a timeout argument. When set to > 0 reboot2() will
block until the timeout is reached, if timeout is set to zero reboot2() will
not block, if set to -1 reboot2() will block indefinitly.
The struct state_client gets rename to lxc_state_client since it's more in line
with other declarations. It also gets moved from the lxc_handler to the
lxc_conf struct so that the state clients waiting for reboots don't get
deallocated on reboot since the handler is deallocated on reboot.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
- setting the handler->state value is atomic on any POSIX implementation since
we're dealing with an integer (enum/lxc_state_t)
- while the state clients are served it is not possible for lxc_set_state() to
transition to the next state anyway so there's no danger in moving to the
next state with clients missing it
- we only care about the list being modified
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
There are multiple reasons why this is not required:
- every command is transactional
- we only care about the list being modified not the memory allocation and
other costly operations
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
We're dealing with an integer (lxc_state_t which is an enum). Any POSIX
implementation makes those operations atomic so there's not need in locking
this.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When we remove a state client fd there's not reason to walk the whole list. We
can simply break once we found and removed the fd.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
