There's no obvious need to strdup() the name of the container in the handler.
We can simply make this a pointer to the memory allocated in
lxc_container_new().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Some toolchains which are not bionic like uclibc does not support
prlimit or prlimit64. In this case, return an error.
Moreover, if prlimit64 is available, use lxc implementation of prlimit.
In case cgroup namespaces are supported but we do not have CAP_SYS_ADMIN we
need to mount cgroups for the container. This patch enables both privileged and
unprivileged containers without CAP_SYS_ADMIN.
Closes #1737.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When attaching to a container's namespaces we did not handle the case where we
inherited namespaces correctly. In essence, liblxc on start records the
namespaces the container was created with in the handler. But it only records
the clone flags that were passed to clone() and doesn't record the namespaces
we e.g. inherited from other containers. This means that attach only ever
attached to the clone flags. But this is only correct if all other namespaces
not recorded in the handler refer to the namespaces of the caller. However,
this need not be the case if the container has inherited namespaces from
another container. To handle this case we need to check whether caller and
container are in the same namespace. If they are, we know that things are all
good. If they aren't then we need to attach to these namespaces as well.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Antonio Terceiro [Sat, 28 Oct 2017 11:20:35 +0000 (09:20 -0200)]
lxc-debian: don't hardcode valid releases
This avoids the dance of updating the list of valid releases every time
Debian makes a new release.
It also fixes the following bug: even though lxc-debian will default to
creating containers of the latest stable by querying the archive, it
won't allow you to explicitly request `stable` because the current list
of valid releases don't include it.
Last, but not least, avoid hitting the mirror in the case the desired
release is one of the ones we know will always be there, i.e. stable,
testing, sid, and unstable.
Signed-off-by: Antonio Terceiro <terceiro@debian.org>
Antonio Terceiro [Thu, 26 Oct 2017 22:42:49 +0000 (20:42 -0200)]
lxc-debian: allow creating `testing` and `unstable`
Being able to create `testing` containers, regardless of what's the name
of the next stable, is useful in several contexts, included but not
limited to testing purposes. i.e. one won't need to explicitly switch to
`bullseye` once `buster` is released to be able to continue tracking
`testing`. While we are at it, let's also enable `unstable`, which is
exactly the same as `sid`, but there is no reason for not being able to.
Signed-off-by: Antonio Terceiro <terceiro@debian.org>
Adam Borowski [Sun, 15 Oct 2017 19:20:34 +0000 (19:20 +0000)]
Use the proper type for rlim_t, fixing build failure on x32.
Assuming a particular width of a type (or equivalence with "long") doesn't
work everywhere. On new architectures, LFS/etc is enabled by default,
making rlim_t same as rlim64_t even if long is only 32-bit.
Not sure how you handle too big values -- you may want to re-check the
strtoull part.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
The kernel only allows 4k writes to most files in /proc including {g,u}id_map
so let's not try to write partial mappings. (This will obviously become a lot
more relevant when my patch to extend the idmap limit in the kernel is merged.)
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
With the release LXC 2.1 we started warning users who use LXC through the API
and users who use LXC through the tools equally about updating their config.
This quickly got confusing and annoying to API users who e.g. generate configs
on the fly (e.g. LXD). So instead of unconditionally warning users we make this
opt-in. If LXC detects that the env variable LXC_UPDATE_CONFIG_FORMAT is set
then it will warn the user if any legacy configuration keys are present. If it
is not set however, it will not warn the user. This is ok, since the log will
still log WARN()s for all legacy configuration keys.
The tools will all set LXC_UPDATE_CONFIG_FORMAT since it is very much required
that users update to the new configuration format pre-LXC 3.0.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
```
# this only works if we have getty@.service to manipulate
if [ -f "${rootfs}/lib/systemd/system/getty@.service" ]; then
sed -e 's/^ConditionPathExists=/# ConditionPathExists=/' \
-e 's/After=dev-%i.device/After=/' \
< "${rootfs}/lib/systemd/system/getty@.service" \
> "${rootfs}/etc/systemd/system/getty@.service"
fi
```
we have only /dev/tty in a container - so this little cutie will spam the log all 10s with the following:
```
Jul 28 22:33:00 mariadb systemd[1]: getty@tty4.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty3.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty2.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:00 mariadb systemd[1]: Stopped Getty on tty2.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty2.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty2.service, ignoring: Operation not permitted
Jul 28 22:33:00 mariadb systemd[1]: Started Getty on tty2.
Jul 28 22:33:00 mariadb systemd[1]: Stopped Getty on tty1.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty1.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty1.service, ignoring: Operation not permitted
Jul 28 22:33:00 mariadb systemd[1]: Started Getty on tty1.
Jul 28 22:33:00 mariadb systemd[1]: Stopped Getty on tty3.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty3.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty3.service, ignoring: Operation not permitted
Jul 28 22:33:00 mariadb systemd[1]: Started Getty on tty3.
Jul 28 22:33:00 mariadb systemd[1]: Stopped Getty on tty4.
Jul 28 22:33:00 mariadb systemd[1]: getty@tty4.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty4.service, ignoring: Operation not permitted
Jul 28 22:33:00 mariadb systemd[1]: Started Getty on tty4.
Jul 28 22:33:00 mariadb agetty[242]: /dev/tty1: cannot open as standard input: No such file or directory
Jul 28 22:33:00 mariadb agetty[241]: /dev/tty2: cannot open as standard input: No such file or directory
Jul 28 22:33:00 mariadb agetty[244]: /dev/tty4: cannot open as standard input: No such file or directory
Jul 28 22:33:00 mariadb agetty[243]: /dev/tty3: cannot open as standard input: No such file or directory
Jul 28 22:33:10 mariadb systemd[1]: getty@tty4.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty2.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty3.service: Service has no hold-off time, scheduling restart.
Jul 28 22:33:10 mariadb systemd[1]: Stopped Getty on tty3.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty3.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty3.service, ignoring: Operation not permitted
Jul 28 22:33:10 mariadb systemd[1]: Started Getty on tty3.
Jul 28 22:33:10 mariadb systemd[1]: Stopped Getty on tty1.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty1.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty1.service, ignoring: Operation not permitted
Jul 28 22:33:10 mariadb systemd[1]: Started Getty on tty1.
Jul 28 22:33:10 mariadb systemd[1]: Stopped Getty on tty2.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty2.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty2.service, ignoring: Operation not permitted
Jul 28 22:33:10 mariadb systemd[1]: Started Getty on tty2.
Jul 28 22:33:10 mariadb systemd[1]: Stopped Getty on tty4.
Jul 28 22:33:10 mariadb systemd[1]: getty@tty4.service: Failed to set invocation ID on control group /system.slice/system-getty.slice/getty@tty4.service, ignoring: Operation not permitted
Jul 28 22:33:10 mariadb systemd[1]: Started Getty on tty4.
Jul 28 22:33:10 mariadb agetty[245]: /dev/tty3: cannot open as standard input: No such file or directory
Jul 28 22:33:10 mariadb agetty[247]: /dev/tty2: cannot open as standard input: No such file or directory
Jul 28 22:33:10 mariadb agetty[246]: /dev/tty1: cannot open as standard input: No such file or directory
Jul 28 22:33:10 mariadb agetty[248]: /dev/tty4: cannot open as standard input: No such file or directory
```
if more reasons are whished i could attach the logs from 10 containers after one month runtime. (approx 30G)
We need to clear any ifindeces we recorded so liblxc won't have cached stale
data which would cause it to fail on reboot we're we don't re-read the on-disk
config file.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Change file check to also check file size (`-f` => `-s`)
Because the `fetch` wget wrapper outputs files to stdout we may end up in a
situation where wget fails but the files are still created. This can happen
e.g. when the host date is out of sync leading to a failed certificate
check, resulting in the creation of empty key files.
Once the empty files have been created the template will try to use them which
causes the certificate check to fail.
By using `-s` instead of `-f` the template will re-fetch the files unless they
exist AND have a size greater than zero.
To match names beginning with the letters "f" or "b" one can use
the regular expression "[fb].*" or "(f|b).*", but not "[f|b].*",
which would match strings beginning with "f", "|", or "b".
Signed-off-by: Christian von Roques <roques@z12.ch>
plamo: Delete unnecessary process during container shutdown
Since some remounts/umounts is executed in the plamo shutdown script,
the filesystem on where a container exists might be mount as
read-only. This patch delete some mounts and umounts from the shutdown
script. It also delete hwclock setting process.
This is technically not necessary but it is a privilege sensitive operation.
Meaning if anyone wants to do something that requires privilege it should be
done before the id switch. So let's move the id switch immediately before the
exec so that it's called at the last possible moment.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
In the past, if the console client exited, lxc_console_cb_con return 1. And
the lxc_poll will exit, the process will wait at waitpid. At this moment, the
process could not handle any command (For example get the container state
LXC_CMD_GET_STATE or stop the container LXC_CMD_STOP.).
I think we should clean the tty_state and return 0 in this case. So, we can use
the lxc-console to connect the console of the container. And we will not exit
the function lxc_polland we can handle the commands by lxc_cmd_process
Reproducer prior to this commit:
- open a new terminal, get the tty device name by command tty /dev/pts/6
- set lxc.console.path = /dev/pts/6
- start the container and the ouptut will print to /dev/pts/6
- close /dev/pts/6
- try an operation e.g. getting state with lxc-ls and lxc-ls will hang
Closes #1787.
Signed-off-by: LiFeng <lifeng68@huawei.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
A bit of context:
userns_exec_1() is only used to operate based on privileges for the user's own
{g,u}id on the host and for the container root's unmapped {g,u}id. This means
we require only to establish a mapping from:
- the container root {g,u}id as seen from the host -> user's host {g,u}id
- the container root -> some sub{g,u}id
This function however was buggy. It relied on some pointer pointing to the same
memory, namely specific idmap entries in the idmap list in the container's
in-memory configuration. However, due to a stupid mistake of mine, the pointers
to be compared pointed to freshly allocated memory. They were never pointing to
the intended memory locations. To reproduce what I'm talking about prior to
this commit simply place:
projects / thirdparty / lxc.git / log
