We have an extensive set of container config options to do this
for us, and doing this unconditionally breaks several use cases.
For instance, if we want to bind mount a /dev/shm using the
container configuration, then lxc-execute, then lxc-init will
rudely unmount the /dev/shm and remount it as a private tmpfs.
Signed-off-by: Serge Hallyn <shallyn@cisco.com>
The console ringbuffer will be dumped to disk if the console log file is not
rotated and it's size is not unlimited. In the former two cases we will have
all data from the ringbuffer available anyway.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
lxc.console.size regulates the size of the console log file. This is intended
to replace lxc.console.buffer.logfile. The current semantics are:
- if lxc.console.size is not set:
- no limit is placed on the size of the log file
- if lxc.console.size is set:
- if lxc.console.rotate is set and the next write would exceed the limit:
- write as much as possible into the old log file
- rotate the log file
- write as much as posible into the new log file
- discard remaining bytes (scenario shouldn't be possible in normal
circumstances)
- if lxc.console.rotate is not set and the next write would exceed the limit:
- keep overwriting the current log file
To make the log file a mirror of the in-memory ringbuffer simply set:
lxc.console.buffer.size == lxc.console.size.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
I was thinking about the locking here yesterday and it dawned on me that we
actually don't need this at all:
- possible contention between traversing list to send states to state clients
and adding new state clients to the list:
It is the command handler that adds new state clients to the state client
list. The command handler and the code that actually sends out the container
states run in the same process so there's not contention and thus no locking
needed.
- adding state clients to the list from multiple threads:
The command handler itself is single-threaded so only one thread's request can
be served at the same time so no locking is needed.
- sending out the state to state clients via the command handler itself:
The state client also adds and removes state clients from the state client
list so there's no locking needed.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
* prepend $LXC_PATH to $DOWNLOAD_TEMP on systems with /tmp mounted
securely as a small tmpfs / noexec
* gpg_setup() creates $DOWNLOAD_TEMP so remove superflous mkdir
* fixes https://github.com/lxc/lxc/issues/516
Signed-off-by: Stuart Cardall <developer@it-offshore.co.uk>
