Discussion:
Unable to Start Unprivileged Containers on Debian / Jessie
(too old to reply)
Chris
2014-09-21 16:22:55 UTC
Permalink
Hi,

For the last few days I've been attempting to run an unprivileged
container on Jessie without much luck, I was hoping someone might be
able to steer me in the right direction.

socrates at plato:~$ . /etc/*release; echo $PRETTY_NAME
Debian GNU/Linux jessie/sid
socrates at plato:~$ uname -a
Linux plato 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09)
x86_64 GNU/Linux
socrates at plato:~$ dpkg-query -l lxc
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description
+++-==============================-====================-====================-=================================================================
ii lxc 1:1.0.5-3 amd64
Linux Containers userspace tools
socrates at plato:~$ socrates at plato:~$ cat
/sys/fs/cgroup/cpuset/cgroup.clone_children
/proc/sys/kernel/unprivileged_userns_clone
1
1

So just running it straight off gives me the following.

socrates at plato:~$ lxc-start -d -n socrates --logfile ~/x
--logpriority=TRACE
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options.

With this coming up in the log:

lxc-start 1411313929.470 INFO lxc_start_ui - using rcfile
/home/socrates/.local/share/lxc/socrates/config
lxc-start 1411313929.520 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.540 INFO lxc_confile - read uid map:
type u nsid 0 hostid 427680 range 65536
lxc-start 1411313929.540 INFO lxc_confile - read uid map:
type g nsid 0 hostid 427680 range 65536
lxc-start 1411313929.541 WARN lxc_log - lxc_log_init called
with log already initialized
lxc-start 1411313929.567 INFO lxc_lsm - LSM security driver nop
lxc-start 1411313929.568 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.570 DEBUG lxc_conf - allocated pty
'/dev/pts/2' (5/6)
lxc-start 1411313929.570 INFO lxc_conf - tty's configured
lxc-start 1411313929.570 DEBUG lxc_start - sigchild handler set
lxc-start 1411313929.571 DEBUG lxc_console - opening
/home/socrates/.console for console peer
lxc-start 1411313929.571 DEBUG lxc_console - using
'/home/socrates/.console' as console
lxc-start 1411313929.571 DEBUG lxc_console - no console peer
lxc-start 1411313929.575 INFO lxc_monitor - using monitor
sock name lxc/5a8aaa9d4fd81a5c//home/socrates/.local/share/lxc
lxc-start 1411313929.860 INFO lxc_start - 'socrates' is
initialized
lxc-start 1411313929.891 DEBUG lxc_start - Not dropping
cap_sys_boot or watching utmp
lxc-start 1411313929.891 INFO lxc_start - Cloning a new user
namespace
lxc-start 1411313929.891 INFO lxc_cgroup - cgroup driver
cgroupfs initing for socrates
lxc-start 1411313929.892 ERROR lxc_cgfs - Permission denied -
Could not create cgroup '/socrates' in '/sys/fs/cgroup/perf_event'.
lxc-start 1411313929.892 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/
lxc-start 1411313929.893 ERROR lxc_start - failed creating cgroups
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.894 ERROR lxc_start - failed to spawn
'socrates'
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.894 WARN lxc_commands - command
get_cgroup failed to receive response
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup cpuset unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup cpu unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup devices unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup freezer unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup net_cls unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup blkio unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.895 WARN lxc_cgfs - Not attaching to
cgroup perf_event unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313934.900 ERROR lxc_start_ui - The
lxc-start 1411313934.900 ERROR lxc_start_ui - To get more
details, run the container in
lxc-start 1411313934.900 ERROR lxc_start_ui - Additional
information can be obtained by setting the --logfile and --log-priority
options.

Looking at mailing list posts/etc, I came across this script (from
Serge, if I recall correctly) and have attempted to run it prior to
starting the container, however this seems to cause it to try to create
a new cgroup (socrates-1) seeing that socrates is in use...

socrates at plato:~$ cat prep.sh
#!/bin/bash --
for d in /sys/fs/cgroup/*; do
f=$(basename $d)
echo "looking at $f"
if [ "$f" = "cpuset" ]; then
echo 1 | sudo tee -a $d/cgroup.clone_children;
elif [ "$f" = "memory" ]; then
echo 1 | sudo tee -a $d/memory.use_hierarchy;
fi
sudo mkdir -p $d/$USER
sudo chown -R $USER $d/$USER
echo $$ > $d/$USER/tasks
done
socrates at plato:~$ ./prep.sh
looking at blkio
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ lxc-start -d -n socrates --logfile ~/x
--logpriority=TRACE
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options.

The log output:

lxc-start 1411313677.267 INFO lxc_start_ui - using rcfile
/home/socrates/.local/share/lxc/socrates/config
lxc-start 1411313677.267 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.269 INFO lxc_confile - read uid map:
type u nsid 0 hostid 427680 range 65536
lxc-start 1411313677.269 INFO lxc_confile - read uid map:
type g nsid 0 hostid 427680 range 65536
lxc-start 1411313677.269 WARN lxc_log - lxc_log_init called
with log already initialized
lxc-start 1411313677.276 INFO lxc_lsm - LSM security driver nop
lxc-start 1411313677.276 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.279 DEBUG lxc_conf - allocated pty
'/dev/pts/2' (5/6)
lxc-start 1411313677.279 INFO lxc_conf - tty's configured
lxc-start 1411313677.279 DEBUG lxc_start - sigchild handler set
lxc-start 1411313677.279 DEBUG lxc_console - opening
/home/socrates/.console for console peer
lxc-start 1411313677.279 DEBUG lxc_console - using
'/home/socrates/.console' as console
lxc-start 1411313677.280 DEBUG lxc_console - no console peer
lxc-start 1411313677.285 INFO lxc_monitor - using monitor
sock name lxc/5a8aaa9d4fd81a5c//home/socrates/.local/share/lxc
lxc-start 1411313677.564 INFO lxc_start - 'socrates' is
initialized
lxc-start 1411313677.575 DEBUG lxc_start - Not dropping
cap_sys_boot or watching utmp
lxc-start 1411313677.576 INFO lxc_start - Cloning a new user
namespace
lxc-start 1411313677.576 INFO lxc_cgroup - cgroup driver
cgroupfs initing for socrates
lxc-start 1411313677.576 ERROR lxc_cgfs - Permission denied -
Could not create cgroup '/socrates-1' in '/sys/fs/cgroup/perf_event'.
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event//socrates
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio//socrates
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/
lxc-start 1411313677.579 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset//socrates
lxc-start 1411313677.579 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/
lxc-start 1411313677.579 ERROR lxc_start - failed creating cgroups
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.579 ERROR lxc_start - failed to spawn
'socrates'
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.579 WARN lxc_commands - command
get_cgroup failed to receive response
lxc-start 1411313677.579 WARN lxc_cgfs - Not attaching to
cgroup cpuset unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.579 WARN lxc_cgfs - Not attaching to
cgroup cpu unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup devices unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup freezer unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup net_cls unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup blkio unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup perf_event unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313682.585 ERROR lxc_start_ui - The container
failed to start.
lxc-start 1411313682.585 ERROR lxc_start_ui - To get more
details, run the container in foreground mode.
lxc-start 1411313682.585 ERROR lxc_start_ui - Additional
information can be obtained by setting the --logfile and --log-priority
options.

Any advice would be much appreciated, I've spent quite a while scouring
the Internet for ideas, but now I am stuck.

Thanks,
Chris
J Bc
2014-09-21 16:33:35 UTC
Permalink

Hi,
For the last few days I've been attempting to run an unprivileged container
on Jessie without much luck, I was hoping someone might be able to steer me
in the right direction.
socrates at plato:~$ . /etc/*release; echo $PRETTY_NAME
Debian GNU/Linux jessie/sid
socrates at plato:~$ uname -a
Linux plato 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64
GNU/Linux
socrates at plato:~$ dpkg-query -l lxc
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description
+++-==============================-====================-====================-=================================================================
ii lxc 1:1.0.5-3 amd64
Linux Containers userspace tools
socrates at plato:~$ socrates at plato:~$ cat
/sys/fs/cgroup/cpuset/cgroup.clone_children
/proc/sys/kernel/unprivileged_userns_clone
1
1
So just running it straight off gives me the following.
socrates at plato:~$ lxc-start -d -n socrates --logfile ~/x
--logpriority=TRACE
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options.
lxc-start 1411313929.470 INFO lxc_start_ui - using rcfile
/home/socrates/.local/share/lxc/socrates/config
lxc-start 1411313929.520 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313929.540 INFO lxc_confile - read uid map: type u
nsid 0 hostid 427680 range 65536
lxc-start 1411313929.540 INFO lxc_confile - read uid map: type g
nsid 0 hostid 427680 range 65536
lxc-start 1411313929.541 WARN lxc_log - lxc_log_init called with
log already initialized
lxc-start 1411313929.567 INFO lxc_lsm - LSM security driver nop
lxc-start 1411313929.568 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313929.570 DEBUG lxc_conf - allocated pty
'/dev/pts/2' (5/6)
lxc-start 1411313929.570 INFO lxc_conf - tty's configured
lxc-start 1411313929.570 DEBUG lxc_start - sigchild handler set
lxc-start 1411313929.571 DEBUG lxc_console - opening
/home/socrates/.console for console peer
lxc-start 1411313929.571 DEBUG lxc_console - using
'/home/socrates/.console' as console
lxc-start 1411313929.571 DEBUG lxc_console - no console peer
lxc-start 1411313929.575 INFO lxc_monitor - using monitor sock
name lxc/5a8aaa9d4fd81a5c//home/socrates/.local/share/lxc
lxc-start 1411313929.860 INFO lxc_start - 'socrates' is
initialized
lxc-start 1411313929.891 DEBUG lxc_start - Not dropping
cap_sys_boot or watching utmp
lxc-start 1411313929.891 INFO lxc_start - Cloning a new user
namespace
lxc-start 1411313929.891 INFO lxc_cgroup - cgroup driver cgroupfs
initing for socrates
lxc-start 1411313929.892 ERROR lxc_cgfs - Permission denied - Could
not create cgroup '/socrates' in '/sys/fs/cgroup/perf_event'.
lxc-start 1411313929.892 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/
lxc-start 1411313929.893 ERROR lxc_start - failed creating cgroups
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313929.894 ERROR lxc_start - failed to spawn
'socrates'
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313929.894 WARN lxc_commands - command get_cgroup
failed to receive response
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to cgroup
cpuset unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to cgroup
cpu unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to cgroup
devices unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to cgroup
freezer unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to cgroup
net_cls unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to cgroup
blkio unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.895 WARN lxc_cgfs - Not attaching to cgroup
perf_event unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313934.900 ERROR lxc_start_ui - The
lxc-start 1411313934.900 ERROR lxc_start_ui - To get more details,
run the container in
lxc-start 1411313934.900 ERROR lxc_start_ui - Additional
information can be obtained by setting the --logfile and --log-priority
options.
Looking at mailing list posts/etc, I came across this script (from Serge, if
I recall correctly) and have attempted to run it prior to starting the
container, however this seems to cause it to try to create a new cgroup
(socrates-1) seeing that socrates is in use...
socrates at plato:~$ cat prep.sh
#!/bin/bash --
for d in /sys/fs/cgroup/*; do
f=$(basename $d)
echo "looking at $f"
if [ "$f" = "cpuset" ]; then
echo 1 | sudo tee -a $d/cgroup.clone_children;
elif [ "$f" = "memory" ]; then
echo 1 | sudo tee -a $d/memory.use_hierarchy;
fi
sudo mkdir -p $d/$USER
sudo chown -R $USER $d/$USER
echo $$ > $d/$USER/tasks
done
socrates at plato:~$ ./prep.sh
looking at blkio
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ lxc-start -d -n socrates --logfile ~/x
--logpriority=TRACE
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options.
lxc-start 1411313677.267 INFO lxc_start_ui - using rcfile
/home/socrates/.local/share/lxc/socrates/config
lxc-start 1411313677.267 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313677.269 INFO lxc_confile - read uid map: type u
nsid 0 hostid 427680 range 65536
lxc-start 1411313677.269 INFO lxc_confile - read uid map: type g
nsid 0 hostid 427680 range 65536
lxc-start 1411313677.269 WARN lxc_log - lxc_log_init called with
log already initialized
lxc-start 1411313677.276 INFO lxc_lsm - LSM security driver nop
lxc-start 1411313677.276 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313677.279 DEBUG lxc_conf - allocated pty
'/dev/pts/2' (5/6)
lxc-start 1411313677.279 INFO lxc_conf - tty's configured
lxc-start 1411313677.279 DEBUG lxc_start - sigchild handler set
lxc-start 1411313677.279 DEBUG lxc_console - opening
/home/socrates/.console for console peer
lxc-start 1411313677.279 DEBUG lxc_console - using
'/home/socrates/.console' as console
lxc-start 1411313677.280 DEBUG lxc_console - no console peer
lxc-start 1411313677.285 INFO lxc_monitor - using monitor sock
name lxc/5a8aaa9d4fd81a5c//home/socrates/.local/share/lxc
lxc-start 1411313677.564 INFO lxc_start - 'socrates' is
initialized
lxc-start 1411313677.575 DEBUG lxc_start - Not dropping
cap_sys_boot or watching utmp
lxc-start 1411313677.576 INFO lxc_start - Cloning a new user
namespace
lxc-start 1411313677.576 INFO lxc_cgroup - cgroup driver cgroupfs
initing for socrates
lxc-start 1411313677.576 ERROR lxc_cgfs - Permission denied - Could
not create cgroup '/socrates-1' in '/sys/fs/cgroup/perf_event'.
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event//socrates
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio//socrates
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/
lxc-start 1411313677.579 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset//socrates
lxc-start 1411313677.579 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/
lxc-start 1411313677.579 ERROR lxc_start - failed creating cgroups
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313677.579 ERROR lxc_start - failed to spawn
'socrates'
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR isn't
set in the environment.
lxc-start 1411313677.579 WARN lxc_commands - command get_cgroup
failed to receive response
lxc-start 1411313677.579 WARN lxc_cgfs - Not attaching to cgroup
cpuset unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.579 WARN lxc_cgfs - Not attaching to cgroup
cpu unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to cgroup
devices unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to cgroup
freezer unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to cgroup
net_cls unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to cgroup
blkio unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to cgroup
perf_event unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313682.585 ERROR lxc_start_ui - The container failed
to start.
lxc-start 1411313682.585 ERROR lxc_start_ui - To get more details,
run the container in foreground mode.
lxc-start 1411313682.585 ERROR lxc_start_ui - Additional
information can be obtained by setting the --logfile and --log-priority
options.
Any advice would be much appreciated, I've spent quite a while scouring the
Internet for ideas, but now I am stuck.
Thanks,
Chris
_______________________________________________
lxc-users mailing list
lxc-users at lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Naoki Kawakami
2014-09-22 02:26:23 UTC
Permalink
Hi Chris,

Insure your plato user indeed has write access to the cgroups created by
prep.sh and that the bash PID which would run lxc-start is indeed in the
tasks file of each created cgroup.
I remember having to edit this script because it did not work for me as
is (though I am not on debian-based OS).

kind regards
Post by Chris
Hi,
For the last few days I've been attempting to run an unprivileged
container on Jessie without much luck, I was hoping someone might be
able to steer me in the right direction.
socrates at plato:~$ . /etc/*release; echo $PRETTY_NAME
Debian GNU/Linux jessie/sid
socrates at plato:~$ uname -a
Linux plato 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09)
x86_64 GNU/Linux
socrates at plato:~$ dpkg-query -l lxc
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============================-====================-====================-=================================================================
ii lxc 1:1.0.5-3 amd64 Linux
Containers userspace tools
socrates at plato:~$ socrates at plato:~$ cat
/sys/fs/cgroup/cpuset/cgroup.clone_children
/proc/sys/kernel/unprivileged_userns_clone
1
1
So just running it straight off gives me the following.
socrates at plato:~$ lxc-start -d -n socrates --logfile ~/x
--logpriority=TRACE
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options.
lxc-start 1411313929.470 INFO lxc_start_ui - using rcfile
/home/socrates/.local/share/lxc/socrates/config
lxc-start 1411313929.520 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
type u nsid 0 hostid 427680 range 65536
type g nsid 0 hostid 427680 range 65536
lxc-start 1411313929.541 WARN lxc_log - lxc_log_init called
with log already initialized
lxc-start 1411313929.567 INFO lxc_lsm - LSM security driver nop
lxc-start 1411313929.568 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.570 DEBUG lxc_conf - allocated pty
'/dev/pts/2' (5/6)
lxc-start 1411313929.570 INFO lxc_conf - tty's configured
lxc-start 1411313929.570 DEBUG lxc_start - sigchild handler set
lxc-start 1411313929.571 DEBUG lxc_console - opening
/home/socrates/.console for console peer
lxc-start 1411313929.571 DEBUG lxc_console - using
'/home/socrates/.console' as console
lxc-start 1411313929.571 DEBUG lxc_console - no console peer
lxc-start 1411313929.575 INFO lxc_monitor - using monitor
sock name lxc/5a8aaa9d4fd81a5c//home/socrates/.local/share/lxc
lxc-start 1411313929.860 INFO lxc_start - 'socrates' is
initialized
lxc-start 1411313929.891 DEBUG lxc_start - Not dropping
cap_sys_boot or watching utmp
lxc-start 1411313929.891 INFO lxc_start - Cloning a new user
namespace
lxc-start 1411313929.891 INFO lxc_cgroup - cgroup driver
cgroupfs initing for socrates
lxc-start 1411313929.892 ERROR lxc_cgfs - Permission denied -
Could not create cgroup '/socrates' in '/sys/fs/cgroup/perf_event'.
lxc-start 1411313929.892 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/
lxc-start 1411313929.893 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/
lxc-start 1411313929.893 ERROR lxc_start - failed creating cgroups
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.894 ERROR lxc_start - failed to spawn
'socrates'
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.894 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313929.894 WARN lxc_commands - command
get_cgroup failed to receive response
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup cpuset unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup cpu unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup devices unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup freezer unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup net_cls unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.894 WARN lxc_cgfs - Not attaching to
cgroup blkio unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313929.895 WARN lxc_cgfs - Not attaching to
cgroup perf_event unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313934.900 ERROR lxc_start_ui - The
lxc-start 1411313934.900 ERROR lxc_start_ui - To get more
details, run the container in
lxc-start 1411313934.900 ERROR lxc_start_ui - Additional
information can be obtained by setting the --logfile and --log-priority
options.
Looking at mailing list posts/etc, I came across this script (from
Serge, if I recall correctly) and have attempted to run it prior to
starting the container, however this seems to cause it to try to create
a new cgroup (socrates-1) seeing that socrates is in use...
socrates at plato:~$ cat prep.sh
#!/bin/bash --
for d in /sys/fs/cgroup/*; do
f=$(basename $d)
echo "looking at $f"
if [ "$f" = "cpuset" ]; then
echo 1 | sudo tee -a $d/cgroup.clone_children;
elif [ "$f" = "memory" ]; then
echo 1 | sudo tee -a $d/memory.use_hierarchy;
fi
sudo mkdir -p $d/$USER
sudo chown -R $USER $d/$USER
echo $$ > $d/$USER/tasks
done
socrates at plato:~$ ./prep.sh
looking at blkio
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ lxc-start -d -n socrates --logfile ~/x
--logpriority=TRACE
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options.
lxc-start 1411313677.267 INFO lxc_start_ui - using rcfile
/home/socrates/.local/share/lxc/socrates/config
lxc-start 1411313677.267 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
type u nsid 0 hostid 427680 range 65536
type g nsid 0 hostid 427680 range 65536
lxc-start 1411313677.269 WARN lxc_log - lxc_log_init called
with log already initialized
lxc-start 1411313677.276 INFO lxc_lsm - LSM security driver nop
lxc-start 1411313677.276 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.279 DEBUG lxc_conf - allocated pty
'/dev/pts/2' (5/6)
lxc-start 1411313677.279 INFO lxc_conf - tty's configured
lxc-start 1411313677.279 DEBUG lxc_start - sigchild handler set
lxc-start 1411313677.279 DEBUG lxc_console - opening
/home/socrates/.console for console peer
lxc-start 1411313677.279 DEBUG lxc_console - using
'/home/socrates/.console' as console
lxc-start 1411313677.280 DEBUG lxc_console - no console peer
lxc-start 1411313677.285 INFO lxc_monitor - using monitor
sock name lxc/5a8aaa9d4fd81a5c//home/socrates/.local/share/lxc
lxc-start 1411313677.564 INFO lxc_start - 'socrates' is
initialized
lxc-start 1411313677.575 DEBUG lxc_start - Not dropping
cap_sys_boot or watching utmp
lxc-start 1411313677.576 INFO lxc_start - Cloning a new user
namespace
lxc-start 1411313677.576 INFO lxc_cgroup - cgroup driver
cgroupfs initing for socrates
lxc-start 1411313677.576 ERROR lxc_cgfs - Permission denied -
Could not create cgroup '/socrates-1' in '/sys/fs/cgroup/perf_event'.
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event//socrates
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio//socrates
lxc-start 1411313677.577 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct//socrates
lxc-start 1411313677.578 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/
lxc-start 1411313677.579 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset//socrates
lxc-start 1411313677.579 ERROR lxc_cgfs - Permission denied -
cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/
lxc-start 1411313677.579 ERROR lxc_start - failed creating cgroups
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.579 ERROR lxc_start - failed to spawn
'socrates'
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.579 INFO lxc_utils - XDG_RUNTIME_DIR
isn't set in the environment.
lxc-start 1411313677.579 WARN lxc_commands - command
get_cgroup failed to receive response
lxc-start 1411313677.579 WARN lxc_cgfs - Not attaching to
cgroup cpuset unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.579 WARN lxc_cgfs - Not attaching to
cgroup cpu unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup devices unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup freezer unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup net_cls unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup blkio unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313677.580 WARN lxc_cgfs - Not attaching to
cgroup perf_event unknown to /home/socrates/.local/share/lxc socrates
lxc-start 1411313682.585 ERROR lxc_start_ui - The container
failed to start.
lxc-start 1411313682.585 ERROR lxc_start_ui - To get more
details, run the container in foreground mode.
lxc-start 1411313682.585 ERROR lxc_start_ui - Additional
information can be obtained by setting the --logfile and --log-priority
options.
Any advice would be much appreciated, I've spent quite a while scouring
the Internet for ideas, but now I am stuck.
Thanks,
Chris
_______________________________________________
lxc-users mailing list
lxc-users at lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Serge Hallyn
2014-09-22 15:34:06 UTC
Permalink
Post by Naoki Kawakami
Hi Chris,
Insure your plato user indeed has write access to the cgroups
created by prep.sh and that the bash PID which would run lxc-start
is indeed in the tasks file of each created cgroup.
I remember having to edit this script because it did not work for me
as is (though I am not on debian-based OS).
Indeed it looks like that's the problem.

If you are running systemd, logind should be creating your cgroups
(and placing you in them) for you. If not, then you can install
systemd-shim and cgmanager, which should do it for you.

-serge
Chris
2014-09-23 00:16:46 UTC
Permalink
Post by Serge Hallyn
Post by Naoki Kawakami
Hi Chris,
Insure your plato user indeed has write access to the cgroups
created by prep.sh and that the bash PID which would run lxc-start
is indeed in the tasks file of each created cgroup.
I remember having to edit this script because it did not work for me
as is (though I am not on debian-based OS).
This script seems to complete without errors, and I can see what appears
to be the desired effect in the hierarchy. Sorry for making it
confusing. "socrates" is both the unprivileged user, and the container
name. Plato is the physical machine. Putting "Controllers=cpuset cpu
cpuacct memory devices freezer net_cls blkio perf_event" into
/etc/systemd/logind.conf didn't make any difference, incidentally
(systemd version 208-8).

Can someone confirm that the script is/not the problem? Or is there
something I'm missing?

socrates at plato:~$ find /sys/fs/cgroup/ -ls | grep socrates
socrates at plato:~$ ./prep.sh
looking at blkio
[sudo] password for socrates:
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ find /sys/fs/cgroup/ -ls | grep socrates
10533 0 drwxr-xr-x 2 socrates root 60 Sep 23
00:59 /sys/fs/cgroup/cgmanager/socrates
9820 4 -rw-r--r-- 1 socrates socrates 4 Sep
23 00:59 /sys/fs/cgroup/cgmanager/socrates/tasks
10170 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/perf_event/socrates
10174 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/perf_event/socrates/notify_on_release
10173 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/perf_event/socrates/tasks
10172 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/perf_event/socrates/cgroup.clone_children
10171 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/perf_event/socrates/cgroup.procs
9717 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates
9748 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_queued_recursive
9747 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_merged_recursive
9746 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_wait_time_recursive
9745 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_service_time_recursive
9744 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_serviced_recursive
9743 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_service_bytes_recursive
9742 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.sectors_recursive
9741 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.time_recursive
9740 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_queued
9739 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_merged
9738 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_wait_time
9737 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_service_time
9736 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_serviced
9735 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.io_service_bytes
9734 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.sectors
9733 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.time
9732 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.leaf_weight
9731 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.leaf_weight_device
9730 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.weight
9729 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.weight_device
9728 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.throttle.io_serviced
9727 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.throttle.io_service_bytes
9726 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.throttle.write_iops_device
9725 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.throttle.read_iops_device
9724 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.throttle.write_bps_device
9723 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.throttle.read_bps_device
9722 0 --w------- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/blkio.reset_stats
9721 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/notify_on_release
9720 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/tasks
9719 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/cgroup.clone_children
9718 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/blkio/socrates/cgroup.procs
10843 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/net_cls/socrates
10848 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/net_cls/socrates/net_cls.classid
10847 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/net_cls/socrates/notify_on_release
10846 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/net_cls/socrates/tasks
10845 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/net_cls/socrates/cgroup.clone_children
10844 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/net_cls/socrates/cgroup.procs
10062 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates
10069 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/freezer.parent_freezing
10068 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/freezer.self_freezing
10067 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/freezer.state
10066 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/notify_on_release
10065 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/tasks
10064 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/cgroup.clone_children
10063 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/freezer/socrates/cgroup.procs
10014 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates
10021 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/devices.list
10020 0 --w------- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/devices.deny
10019 0 --w------- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/devices.allow
10018 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/notify_on_release
10017 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/tasks
10016 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/cgroup.clone_children
10015 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/devices/socrates/cgroup.procs
9831 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates
9839 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/cpuacct.stat
9838 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/cpuacct.usage_percpu
9837 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/cpuacct.usage
9836 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/cpu.shares
9835 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/notify_on_release
9834 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/tasks
9833 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/cgroup.clone_children
9832 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpu,cpuacct/socrates/cgroup.procs
10724 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates
10739 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.memory_spread_slab
10738 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.memory_spread_page
10737 0 -r--r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.memory_pressure
10736 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.memory_migrate
10735 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.sched_relax_domain_level
10734 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.sched_load_balance
10733 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.mem_hardwall
10732 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.mem_exclusive
10731 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.cpu_exclusive
10730 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.mems
10729 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cpuset.cpus
10728 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/notify_on_release
10727 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/tasks
10726 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cgroup.clone_children
10725 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/cpuset/socrates/cgroup.procs
10215 0 drwxr-xr-x 2 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/systemd/socrates
10219 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/systemd/socrates/notify_on_release
10218 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/systemd/socrates/tasks
10217 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/systemd/socrates/cgroup.clone_children
10216 0 -rw-r--r-- 1 socrates root 0 Sep 23
00:59 /sys/fs/cgroup/systemd/socrates/cgroup.procs
Post by Serge Hallyn
Indeed it looks like that's the problem.
If you are running systemd, logind should be creating your cgroups
(and placing you in them) for you. If not, then you can install
systemd-shim and cgmanager, which should do it for you.
I've tried both systemd and now systemd-shim/cgmanager, they both seem
to fail. The systemd/cgmanager system doesn't allocate cgroups at login
and seems to significantly impair cgroup initiation.

socrates at plato:~$ /etc/init.d/cgmanager status
[ ok ] cgmanager is running.
socrates at plato:~$ find /sys/fs/cgroup/ -ls | grep socrates
socrates at plato:~$ ./prep.sh
looking at cgmanager
[sudo] password for socrates:
socrates at plato:~$ find /sys/fs/cgroup/ -ls | grep socrates
8902 0 drwxr-xr-x 2 socrates root 60 Sep 23
01:10 /sys/fs/cgroup/cgmanager/socrates
8925 4 -rw-r--r-- 1 socrates socrates 5 Sep
23 01:10 /sys/fs/cgroup/cgmanager/socrates/tasks

root at plato:~# lxc-checkconfig | grep required
Cgroup namespace: required
root at plato:~# mount | grep cgroup
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k)

Any thoughts? In the meantime I'll revert the system back to the default
systemd-sysv.
Serge Hallyn
2014-09-23 19:36:54 UTC
Permalink
Post by Chris
Any thoughts? In the meantime I'll revert the system back to the
default systemd-sysv.
Ok, yes let's start back there. "the default systemd-sysv" means
you are running systemd as pid 1, from systemd 215, is that right?
Chris
2014-09-23 23:28:43 UTC
Permalink
Post by Serge Hallyn
Post by Chris
Any thoughts? In the meantime I'll revert the system back to the
default systemd-sysv.
Ok, yes let's start back there. "the default systemd-sysv" means
you are running systemd as pid 1, from systemd 215, is that right?
On my stock Debian/Jessie system I'm running systemd 208 from the looks
of it.

root at plato:~# ps up 1
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 45024 3508 ? Ss Sep23 0:01 /sbin/init
root at plato:~# dpkg -S /sbin/init
systemd-sysv: /sbin/init
root at plato:~# dpkg -l systemd-sysv
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============================-====================-====================-=================================================================
ii systemd-sysv 208-8 amd64 system and
service manager - SysV links
Serge Hallyn
2014-09-24 16:32:45 UTC
Permalink
Post by Chris
Post by Serge Hallyn
Post by Chris
Any thoughts? In the meantime I'll revert the system back to the
default systemd-sysv.
Ok, yes let's start back there. "the default systemd-sysv" means
you are running systemd as pid 1, from systemd 215, is that right?
On my stock Debian/Jessie system I'm running systemd 208 from the
looks of it.
root at plato:~# ps up 1
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 45024 3508 ? Ss Sep23 0:01 /sbin/init
root at plato:~# dpkg -S /sbin/init
systemd-sysv: /sbin/init
root at plato:~# dpkg -l systemd-sysv
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============================-====================-====================-=================================================================
ii systemd-sysv 208-8 amd64 system
and service manager - SysV links
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
Chris
2014-09-24 19:26:00 UTC
Permalink
Post by Serge Hallyn
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
OK. I've got this from a login via SSH immediately following a reboot of
plato.

socrates at plato:~$ find /proc/self/cgroup -ls
10551 0 -r--r--r-- 1 socrates socrates 0 Sep 24
20:23 /proc/self/cgroup
socrates at plato:~$ find /sys/fs/cgroup/freezer -ls
5343 0 drwxr-xr-x 2 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer
5349 0 -rw-r--r-- 1 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer/release_agent
5348 0 -rw-r--r-- 1 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer/notify_on_release
5347 0 -rw-r--r-- 1 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer/tasks
5346 0 -r--r--r-- 1 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer/cgroup.sane_behavior
5345 0 -rw-r--r-- 1 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer/cgroup.clone_children
5344 0 -rw-r--r-- 1 root root 0 Sep 24 20:21
/sys/fs/cgroup/freezer/cgroup.procs
Serge Hallyn
2014-09-24 19:56:26 UTC
Permalink
Post by Chris
Post by Serge Hallyn
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
OK. I've got this from a login via SSH immediately following a
reboot of plato.
socrates at plato:~$ find /proc/self/cgroup -ls
10551 0 -r--r--r-- 1 socrates socrates 0 Sep 24
Oh I meant cat /proc/self/cgroup.
Post by Chris
20:23 /proc/self/cgroup
socrates at plato:~$ find /sys/fs/cgroup/freezer -ls
5343 0 drwxr-xr-x 2 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer
5349 0 -rw-r--r-- 1 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer/release_agent
5348 0 -rw-r--r-- 1 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer/notify_on_release
5347 0 -rw-r--r-- 1 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer/tasks
5346 0 -r--r--r-- 1 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer/cgroup.sane_behavior
5345 0 -rw-r--r-- 1 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer/cgroup.clone_children
5344 0 -rw-r--r-- 1 root root 0 Sep 24
20:21 /sys/fs/cgroup/freezer/cgroup.procs
Chris
2014-09-25 11:38:02 UTC
Permalink
Post by Serge Hallyn
Post by Chris
Post by Serge Hallyn
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
OK. I've got this from a login via SSH immediately following a
reboot of plato.
socrates at plato:~$ find /proc/self/cgroup -ls
10551 0 -r--r--r-- 1 socrates socrates 0 Sep 24
Oh I meant cat /proc/self/cgroup.
Ah, right.

socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:cpu,cpuacct:/
3:cpuset:/
2:name=systemd:/system.slice/ssh.service
Serge Hallyn
2014-09-25 13:49:43 UTC
Permalink
Post by Chris
Post by Serge Hallyn
Post by Chris
Post by Serge Hallyn
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
OK. I've got this from a login via SSH immediately following a
reboot of plato.
socrates at plato:~$ find /proc/self/cgroup -ls
10551 0 -r--r--r-- 1 socrates socrates 0 Sep 24
Oh I meant cat /proc/self/cgroup.
Ah, right.
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:cpu,cpuacct:/
3:cpuset:/
2:name=systemd:/system.slice/ssh.service
Ok, so now you run the prep.sh, then /proc/self/cgroup shows:

socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/socrates
8:blkio:/socrates
7:net_cls:/socrates
6:freezer:/socrates
5:devices:/socrates
4:cpu,cpuacct:/socrates
3:cpuset:/socrates
2:name=systemd:/socrates

? (We'll hope that the name=systemd one isn't a problem). Can you
show the result of

ls -ld /sys/fs/cgroup/freezer/socrates
ls -l /sys/fs/cgroup/freezer/socrates

then finally do the 'lxc-start -n container -l trace -o xxx' and attach
xxx one more time. I've got a bad feeling this won't give *new* info,
but at least I know where we're at at this point. Actually, exactly
how did you create the container? Could you create a new one using the
same command, start it, and make sure it fails the same way? (that
shoudl give me all i need to reproduce)
Chris
2014-09-25 18:21:00 UTC
Permalink
Post by Chris
Post by Chris
Post by Serge Hallyn
Post by Chris
Post by Serge Hallyn
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
OK. I've got this from a login via SSH immediately following a
reboot of plato.
socrates at plato:~$ find /proc/self/cgroup -ls
10551 0 -r--r--r-- 1 socrates socrates 0 Sep 24
Oh I meant cat /proc/self/cgroup.
Ah, right.
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:cpu,cpuacct:/
3:cpuset:/
2:name=systemd:/system.slice/ssh.service
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/socrates
8:blkio:/socrates
7:net_cls:/socrates
6:freezer:/socrates
5:devices:/socrates
4:cpu,cpuacct:/socrates
3:cpuset:/socrates
2:name=systemd:/socrates
? (We'll hope that the name=systemd one isn't a problem). Can you
show the result of
ls -ld /sys/fs/cgroup/freezer/socrates
ls -l /sys/fs/cgroup/freezer/socrates
then finally do the 'lxc-start -n container -l trace -o xxx' and attach
xxx one more time. I've got a bad feeling this won't give *new* info,
but at least I know where we're at at this point. Actually, exactly
how did you create the container? Could you create a new one using the
same command, start it, and make sure it fails the same way? (that
shoudl give me all i need to reproduce)
Looks like the script isn't working right... It doesn't seem to affect
my /proc/self/cgroup. Logging out and back in again didn't seem to
affect it either. Nor did re-running the script.

socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:cpu,cpuacct:/
3:cpuset:/
2:name=systemd:/system.slice/ssh.service
socrates at plato:~$ ./prep.sh
looking at blkio
[sudo] password for socrates:
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:cpu,cpuacct:/
3:cpuset:/
2:name=systemd:/system.slice/ssh.service
socrates at plato:~$ cat ./prep.sh
#!/bin/bash --

for d in /sys/fs/cgroup/*; do
f=$(basename $d)
echo "looking at $f"
if [ "$f" = "cpuset" ]; then
echo 1 | sudo tee -a $d/cgroup.clone_children;
elif [ "$f" = "memory" ]; then
echo 1 | sudo tee -a $d/memory.use_hierarchy;
fi
sudo mkdir -p $d/$USER
sudo chown -R $USER $d/$USER
echo $$ > $d/$USER/tasks
done
Serge Hallyn
2014-09-25 18:43:15 UTC
Permalink
Post by Chris
Post by Chris
Post by Chris
Post by Serge Hallyn
Post by Chris
Post by Serge Hallyn
Ok in that case /sys/fs/cgroup should still be mounted read-write. After
you login, what does /proc/self/cgroup show, and what does the tree under
/sys/fs/cgroup/freezer/ look like?
OK. I've got this from a login via SSH immediately following a
reboot of plato.
socrates at plato:~$ find /proc/self/cgroup -ls
10551 0 -r--r--r-- 1 socrates socrates 0 Sep 24
Oh I meant cat /proc/self/cgroup.
Ah, right.
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:cpu,cpuacct:/
3:cpuset:/
2:name=systemd:/system.slice/ssh.service
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/socrates
8:blkio:/socrates
7:net_cls:/socrates
6:freezer:/socrates
5:devices:/socrates
4:cpu,cpuacct:/socrates
3:cpuset:/socrates
2:name=systemd:/socrates
? (We'll hope that the name=systemd one isn't a problem). Can you
show the result of
ls -ld /sys/fs/cgroup/freezer/socrates
ls -l /sys/fs/cgroup/freezer/socrates
then finally do the 'lxc-start -n container -l trace -o xxx' and attach
xxx one more time. I've got a bad feeling this won't give *new* info,
but at least I know where we're at at this point. Actually, exactly
how did you create the container? Could you create a new one using the
same command, start it, and make sure it fails the same way? (that
shoudl give me all i need to reproduce)
Looks like the script isn't working right... It doesn't seem to
affect my /proc/self/cgroup. Logging out and back in again didn't
D'oh. yeah you cannot have the last line inside a script - it
moves the *script*, not your shell, into the new cgroup :)

So from your shell after running the script, do

for d in /sys/fs/cgroup/*; do
echo $$ > $d/$USER/tasks
done

and that should work.
Chris
2014-09-25 22:35:12 UTC
Permalink
Post by Serge Hallyn
D'oh. yeah you cannot have the last line inside a script - it
moves the *script*, not your shell, into the new cgroup :)
So from your shell after running the script, do
for d in /sys/fs/cgroup/*; do
echo $$ > $d/$USER/tasks
done
and that should work.
Ah, of course! I've switched $$ for $PPID in the script.

socrates at plato:~$ ./prep.sh
looking at blkio
[sudo] password for socrates:
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/socrates
8:blkio:/socrates
7:net_cls:/socrates
6:freezer:/socrates
5:devices:/socrates
4:cpu,cpuacct:/socrates
3:cpuset:/socrates
2:name=systemd:/socrates
socrates at plato:~$ lxc-start -n socrates -l trace -o /tmp/xxx
failed to create /run/lxc
Failed to create directory for db file
lxc-start: failed to create the configured network
lxc-start: failed to spawn 'socrates'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting
the --logfile and --log-priority options.

Seems like a big improvement. I've attached the log file, xxx. Am I
right in thinking that it's having difficulties creating the network
interface?

socrates at plato:~$ cat /etc/lxc/lxc-usernet
socrates veth lxcbr0 1000
socrates at plato:~$ /sbin/ifconfig lxcbr0
lxcbr0 Link encap:Ethernet HWaddr 00:24:21:9b:91:e2
inet addr:192.168.0.10 Bcast:192.168.0.255
Mask:255.255.255.0
inet6 addr: fe80::224:21ff:fe9b:5ab5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7041 errors:0 dropped:0 overruns:0 frame:0
TX packets:1766 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:967017 (944.3 KiB) TX bytes:197970 (193.3
KiB)
socrates at plato:~$ cat .config/lxc/default.conf
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:55:bd:de
lxc.id_map = u 0 427680 65536
lxc.id_map = g 0 427680 65536
socrates at plato:~$ head .local/share/lxc/socrates/config
#
lxc.network.type = veth
#lxc.network.veth.pair = socrates
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:55:bd:de
lxc.id_map = u 0 427680 65536
lxc.id_map = g 0 427680 65536

-------------- next part --------------
lxc-start 1411680899.159 INFO lxc_start_ui - using rcfile /home/socrates/.local/share/lxc/socrates/config
lxc-start 1411680899.159 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411680899.161 INFO lxc_confile - read uid map: type u nsid 0 hostid 427680 range 65536
lxc-start 1411680899.161 INFO lxc_confile - read uid map: type g nsid 0 hostid 427680 range 65536
lxc-start 1411680899.161 WARN lxc_log - lxc_log_init called with log already initialized
lxc-start 1411680899.161 INFO lxc_lsm - LSM security driver nop
lxc-start 1411680899.161 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411680899.162 DEBUG lxc_conf - allocated pty '/dev/pts/1' (5/6)
lxc-start 1411680899.163 INFO lxc_conf - tty's configured
lxc-start 1411680899.163 DEBUG lxc_start - sigchild handler set
lxc-start 1411680899.163 DEBUG lxc_console - opening /home/socrates/.console for console peer
lxc-start 1411680899.163 DEBUG lxc_console - using '/home/socrates/.console' as console
lxc-start 1411680899.163 DEBUG lxc_console - no console peer
lxc-start 1411680899.432 INFO lxc_start - 'socrates' is initialized
lxc-start 1411680899.463 DEBUG lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1411680899.463 INFO lxc_start - Cloning a new user namespace
lxc-start 1411680899.463 INFO lxc_cgroup - cgroup driver cgroupfs initing for socrates
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.deny' set to 'a'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c *:* m'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'b *:* m'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:1 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 10:229 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 254:0 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm'
lxc-start 1411680899.467 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm'
lxc-start 1411680899.467 INFO lxc_cgfs - cgroup has been setup
lxc-start 1411680899.473 ERROR lxc_start - failed to create the configured network
lxc-start 1411680899.473 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411680899.575 ERROR lxc_start - failed to spawn 'socrates'
lxc-start 1411680899.575 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411680899.575 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411680899.577 ERROR lxc_start_ui - The container failed to start.
lxc-start 1411680899.577 ERROR lxc_start_ui - Additional information can be obtained by setting the --logfile and --log-priority options.
Serge Hallyn
2014-09-26 23:02:05 UTC
Permalink
Post by Chris
Post by Serge Hallyn
D'oh. yeah you cannot have the last line inside a script - it
moves the *script*, not your shell, into the new cgroup :)
So from your shell after running the script, do
for d in /sys/fs/cgroup/*; do
echo $$ > $d/$USER/tasks
done
and that should work.
Ah, of course! I've switched $$ for $PPID in the script.
socrates at plato:~$ ./prep.sh
looking at blkio
looking at cgmanager
looking at cpu
looking at cpuacct
looking at cpu,cpuacct
looking at cpuset
1
looking at devices
looking at freezer
looking at net_cls
looking at perf_event
looking at systemd
socrates at plato:~$ cat /proc/self/cgroup
9:perf_event:/socrates
8:blkio:/socrates
7:net_cls:/socrates
6:freezer:/socrates
5:devices:/socrates
4:cpu,cpuacct:/socrates
3:cpuset:/socrates
2:name=systemd:/socrates
socrates at plato:~$ lxc-start -n socrates -l trace -o /tmp/xxx
failed to create /run/lxc
Failed to create directory for db file
lxc-start: failed to create the configured network
lxc-start: failed to spawn 'socrates'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by
setting the --logfile and --log-priority options.
Seems like a big improvement. I've attached the log file, xxx. Am I
right in thinking that it's having difficulties creating the network
interface?
socrates at plato:~$ cat /etc/lxc/lxc-usernet
socrates veth lxcbr0 1000
socrates at plato:~$ /sbin/ifconfig lxcbr0
lxcbr0 Link encap:Ethernet HWaddr 00:24:21:9b:91:e2
inet addr:192.168.0.10 Bcast:192.168.0.255
Mask:255.255.255.0
inet6 addr: fe80::224:21ff:fe9b:5ab5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7041 errors:0 dropped:0 overruns:0 frame:0
TX packets:1766 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:967017 (944.3 KiB) TX bytes:197970
(193.3 KiB)
socrates at plato:~$ cat .config/lxc/default.conf
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:55:bd:de
lxc.id_map = u 0 427680 65536
lxc.id_map = g 0 427680 65536
socrates at plato:~$ head .local/share/lxc/socrates/config
#
lxc.network.type = veth
#lxc.network.veth.pair = socrates
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:55:bd:de
lxc.id_map = u 0 427680 65536
lxc.id_map = g 0 427680 65536
Is /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic (or wherever it
sits) setuid-root?
Chris
2014-09-27 13:06:32 UTC
Permalink
Post by Serge Hallyn
Is /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic (or wherever it
sits) setuid-root?
Yes. This was that problem. To my knowledge this program requires setuid
to be at all useful, so I wonder why it's not distributed as such on
Debian/Jessie.

Now my container seems to be running into another issue, it's having
problems populating /dev, I see on the mailing lists that this (or a
very similar) issue cropped up in February, and had since been patched,
so very likely that I'm still doing something wrong. I've attached the
trace level log detailing initialisation of the container.
-------------- next part --------------
lxc-start 1411807327.376 INFO lxc_start_ui - using rcfile /home/osmium/.local/share/lxc/osmium/config
lxc-start 1411807327.399 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807327.420 INFO lxc_confile - read uid map: type u nsid 0 hostid 427680 range 65536
lxc-start 1411807327.420 INFO lxc_confile - read uid map: type g nsid 0 hostid 427680 range 65536
lxc-start 1411807327.420 WARN lxc_log - lxc_log_init called with log already initialized
lxc-start 1411807327.420 INFO lxc_lsm - LSM security driver nop
lxc-start 1411807327.420 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807327.432 DEBUG lxc_conf - allocated pty '/dev/pts/2' (5/6)
lxc-start 1411807327.432 INFO lxc_conf - tty's configured
lxc-start 1411807327.432 DEBUG lxc_start - sigchild handler set
lxc-start 1411807327.432 DEBUG lxc_console - opening /home/osmium/.console for console peer
lxc-start 1411807327.432 DEBUG lxc_console - using '/home/osmium/.console' as console
lxc-start 1411807327.432 DEBUG lxc_console - no console peer
lxc-start 1411807327.776 INFO lxc_start - 'osmium' is initialized
lxc-start 1411807327.807 DEBUG lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1411807327.807 INFO lxc_start - Cloning a new user namespace
lxc-start 1411807327.807 INFO lxc_cgroup - cgroup driver cgroupfs initing for osmium
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.deny' set to 'a'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c *:* m'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'b *:* m'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:1 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 10:229 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 254:0 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm'
lxc-start 1411807327.811 INFO lxc_cgfs - cgroup has been setup
lxc-start 1411807327.932 NOTICE lxc_start - switching to gid/uid 0 in new user namespace
lxc-start 1411807327.935 DEBUG lxc_conf - mounted '/home/osmium/root' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs'
lxc-start 1411807327.935 INFO lxc_conf - 'osmium' hostname has been setup
lxc-start 1411807327.936 DEBUG lxc_conf - mac address '00:16:3e:73:bd:de' on 'eth0' has been setup
lxc-start 1411807327.936 DEBUG lxc_conf - 'eth0' has been setup
lxc-start 1411807327.936 INFO lxc_conf - network has been setup
lxc-start 1411807327.937 DEBUG lxc_conf - Set exec command to /sbin/init
lxc-start 1411807327.952 INFO lxc_conf - Container with systemd init detected - enabling autodev!
lxc-start 1411807327.952 INFO lxc_conf - Mounting /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.952 DEBUG lxc_conf - entering mount_check_fs for /dev
lxc-start 1411807327.952 DEBUG lxc_conf - mount_check_fs returning 1 last devtmpfs
lxc-start 1411807327.952 INFO lxc_conf - Setup in /dev/.lxc failed. Trying /dev/.lxc/user.
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
lxc-start 1411807327.953 DEBUG lxc_conf - Bind mounting /dev/.lxc/user/osmium.3c68b3f0c5eeec7d to /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1411807327.953 INFO lxc_conf - Mounted /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/proc'
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/dev/pts'
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/sys'
lxc-start 1411807327.953 INFO lxc_conf - mount points have been setup
lxc-start 1411807327.954 INFO lxc_conf - Creating initial consoles under /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1411807327.954 INFO lxc_conf - Populating /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.954 ERROR lxc_conf - Operation not permitted - Error creating null
lxc-start 1411807327.954 ERROR lxc_conf - failed to populate /dev in the container
lxc-start 1411807327.954 ERROR lxc_start - failed to setup the container
lxc-start 1411807327.954 ERROR lxc_sync - invalid sequence number 1. expected 2
lxc-start 1411807327.954 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.067 ERROR lxc_start - failed to spawn 'osmium'
lxc-start 1411807328.068 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.068 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.069 ERROR lxc_start_ui - The container failed to start.
lxc-start 1411807328.069 ERROR lxc_start_ui - Additional information can be obtained by setting the --logfile and --log-priority options.
Serge Hallyn
2014-09-29 20:46:18 UTC
Permalink
Post by Chris
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
Something will need to set that up. I can't recall offhand
what is supposed to do that. Michael (cc:d), is that done
through the init script?

-serge
Post by Chris
Post by Serge Hallyn
Is /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic (or wherever it
sits) setuid-root?
Yes. This was that problem. To my knowledge this program requires
setuid to be at all useful, so I wonder why it's not distributed as
such on Debian/Jessie.
Now my container seems to be running into another issue, it's having
problems populating /dev, I see on the mailing lists that this (or a
very similar) issue cropped up in February, and had since been
patched, so very likely that I'm still doing something wrong. I've
attached the trace level log detailing initialisation of the
container.
lxc-start 1411807327.376 INFO lxc_start_ui - using rcfile /home/osmium/.local/share/lxc/osmium/config
lxc-start 1411807327.399 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807327.420 INFO lxc_confile - read uid map: type u nsid 0 hostid 427680 range 65536
lxc-start 1411807327.420 INFO lxc_confile - read uid map: type g nsid 0 hostid 427680 range 65536
lxc-start 1411807327.420 WARN lxc_log - lxc_log_init called with log already initialized
lxc-start 1411807327.420 INFO lxc_lsm - LSM security driver nop
lxc-start 1411807327.420 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807327.432 DEBUG lxc_conf - allocated pty '/dev/pts/2' (5/6)
lxc-start 1411807327.432 INFO lxc_conf - tty's configured
lxc-start 1411807327.432 DEBUG lxc_start - sigchild handler set
lxc-start 1411807327.432 DEBUG lxc_console - opening /home/osmium/.console for console peer
lxc-start 1411807327.432 DEBUG lxc_console - using '/home/osmium/.console' as console
lxc-start 1411807327.432 DEBUG lxc_console - no console peer
lxc-start 1411807327.776 INFO lxc_start - 'osmium' is initialized
lxc-start 1411807327.807 DEBUG lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1411807327.807 INFO lxc_start - Cloning a new user namespace
lxc-start 1411807327.807 INFO lxc_cgroup - cgroup driver cgroupfs initing for osmium
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.deny' set to 'a'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c *:* m'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'b *:* m'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:1 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 10:229 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 254:0 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm'
lxc-start 1411807327.811 INFO lxc_cgfs - cgroup has been setup
lxc-start 1411807327.932 NOTICE lxc_start - switching to gid/uid 0 in new user namespace
lxc-start 1411807327.935 DEBUG lxc_conf - mounted '/home/osmium/root' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs'
lxc-start 1411807327.935 INFO lxc_conf - 'osmium' hostname has been setup
lxc-start 1411807327.936 DEBUG lxc_conf - mac address '00:16:3e:73:bd:de' on 'eth0' has been setup
lxc-start 1411807327.936 DEBUG lxc_conf - 'eth0' has been setup
lxc-start 1411807327.936 INFO lxc_conf - network has been setup
lxc-start 1411807327.937 DEBUG lxc_conf - Set exec command to /sbin/init
lxc-start 1411807327.952 INFO lxc_conf - Container with systemd init detected - enabling autodev!
lxc-start 1411807327.952 INFO lxc_conf - Mounting /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.952 DEBUG lxc_conf - entering mount_check_fs for /dev
lxc-start 1411807327.952 DEBUG lxc_conf - mount_check_fs returning 1 last devtmpfs
lxc-start 1411807327.952 INFO lxc_conf - Setup in /dev/.lxc failed. Trying /dev/.lxc/user.
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
lxc-start 1411807327.953 DEBUG lxc_conf - Bind mounting /dev/.lxc/user/osmium.3c68b3f0c5eeec7d to /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1411807327.953 INFO lxc_conf - Mounted /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/proc'
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/dev/pts'
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/sys'
lxc-start 1411807327.953 INFO lxc_conf - mount points have been setup
lxc-start 1411807327.954 INFO lxc_conf - Creating initial consoles under /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1411807327.954 INFO lxc_conf - Populating /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.954 ERROR lxc_conf - Operation not permitted - Error creating null
lxc-start 1411807327.954 ERROR lxc_conf - failed to populate /dev in the container
lxc-start 1411807327.954 ERROR lxc_start - failed to setup the container
lxc-start 1411807327.954 ERROR lxc_sync - invalid sequence number 1. expected 2
lxc-start 1411807327.954 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.067 ERROR lxc_start - failed to spawn 'osmium'
lxc-start 1411807328.068 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.068 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.069 ERROR lxc_start_ui - The container failed to start.
lxc-start 1411807328.069 ERROR lxc_start_ui - Additional information can be obtained by setting the --logfile and --log-priority options.
_______________________________________________
lxc-users mailing list
lxc-users at lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Chris
2014-09-30 14:46:31 UTC
Permalink
Post by Serge Hallyn
Post by Chris
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
Something will need to set that up. I can't recall offhand
what is supposed to do that. Michael (cc:d), is that done
through the init script?
-serge
That might make sense, as I created this container through
debootstrapping the filesystem into
/home/osmium/.local/share/lxc/osmium/rootfs and then chown/grping all
the files to the appropriate users in this user's subuid/gid range...
pasted below in case anyone finds it useful. Please let me know if there
are further steps required to make this template/container valid.

Incidentally, I just fixed the "invalid mount point" warnings, they were
just the LXC mount paths not being complete.

$ cat shift_chid.py
#!/usr/bin/env python

import sys
import os

path = sys.argv[1]
offset = int(sys.argv[2])

def logic(path, offset):
stat = os.lstat(path)
o_u = stat.st_uid
o_g = stat.st_gid
n_u = o_u + offset
n_g = o_g + offset
return(path, o_u, o_g, n_u, n_g)

def report(path, offset):
print("Path: %s. Current UID/GID: %s/%s. Proposed UID/GID: %s/%s."
% logic(path, offset))

def chid(path, offset):
p, _, _, u, g = logic(path, offset)
os.lchown(path, u, g)

def verbose(path, offset):
report(path, offset)
chid(path, offset)
report(path, offset)

for cur, dirs, files in os.walk(path):
files.append("")
for x in files:
try:
verbose(os.path.join(cur, x), offset)
except Exception as E:
sys.stderr.write("Error reported: %s" % E)
Michael H. Warfield
2014-09-30 15:47:45 UTC
Permalink
Post by Chris
Post by Serge Hallyn
Post by Chris
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
Something will need to set that up. I can't recall offhand
what is supposed to do that. Michael (cc:d), is that done
through the init script?
-serge
That might make sense, as I created this container through
debootstrapping the filesystem into
/home/osmium/.local/share/lxc/osmium/rootfs and then chown/grping all
the files to the appropriate users in this user's subuid/gid range...
pasted below in case anyone finds it useful. Please let me know if there
are further steps required to make this template/container valid.
You created this with debootstrap? So it's an Ubuntu or Debian
container? Why not use the appropriate lxc-create template? They do a
lot of things that you are unlikely to have done. Since you're creating
a container for an unprivileged user, you should probably have used the
download template, as the live templates are generally for privileged
users only.

That error is generated out of the code, which I authored, that sets up
the autodev device areas and mounts that systemd mandates (but can still
be used by anyone). But, if this is Debian or Ubuntu, what version did
you attempt to install? Unless you're loading a test version, you
shouldn't be getting systemd as your default init system manager (yet).
If you have not explicitly set lxc.autodev = 1 in the config file and
lxc-start does not detect systemd as the init system, you should not
have ventured into that code at all. I'm really baffled how you got in
a situation where you used debootstrap and yet the code is running into
the systemd autodev logic, something I would not have expected for
Ubuntu or Debian just yet (and I don't think those templates are
prepared to set up just yet).

Next question... How did you create your configuration file? That
error message is telling me that either you had lxc.autodev == 1 in the
configuration file OR you're running systemd as your init system
manager. Neither of those should be a particular problem (well, systemd
might if you haven't properly configured certain aspects of the unit
files are startup - but you aren't getting that far) but it's just not
clear how you got where you got doing what you did.

What are the permissions on /home/osmium/.local/share/lxc/osmium ? For
some reason, lxc-start does not have permission to create a symlink in
that directory (or maybe does not have rx read/search permission to all
of its parent directories in the path). That's a short-cut link back to
the hash indexed dev directory under /dev/.lxc/user (for unpriv users)
for the container /dev. Creating that symlink depends only on the
permissions in the path to the directory and the directory itself.

Regards,
Mike
Post by Chris
Incidentally, I just fixed the "invalid mount point" warnings, they were
just the LXC mount paths not being complete.
$ cat shift_chid.py
#!/usr/bin/env python
import sys
import os
path = sys.argv[1]
offset = int(sys.argv[2])
stat = os.lstat(path)
o_u = stat.st_uid
o_g = stat.st_gid
n_u = o_u + offset
n_g = o_g + offset
return(path, o_u, o_g, n_u, n_g)
print("Path: %s. Current UID/GID: %s/%s. Proposed UID/GID: %s/%s."
% logic(path, offset))
p, _, _, u, g = logic(path, offset)
os.lchown(path, u, g)
report(path, offset)
chid(path, offset)
report(path, offset)
files.append("")
verbose(os.path.join(cur, x), offset)
sys.stderr.write("Error reported: %s" % E)
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140930/0afa93e2/attachment.sig>
Chris
2014-09-30 16:45:36 UTC
Permalink
Post by Michael H. Warfield
Post by Chris
Post by Serge Hallyn
Post by Chris
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
Something will need to set that up. I can't recall offhand
what is supposed to do that. Michael (cc:d), is that done
through the init script?
-serge
That might make sense, as I created this container through
debootstrapping the filesystem into
/home/osmium/.local/share/lxc/osmium/rootfs and then chown/grping all
the files to the appropriate users in this user's subuid/gid range...
pasted below in case anyone finds it useful. Please let me know if there
are further steps required to make this template/container valid.
You created this with debootstrap? So it's an Ubuntu or Debian
container? Why not use the appropriate lxc-create template? They do a
lot of things that you are unlikely to have done. Since you're creating
a container for an unprivileged user, you should probably have used the
download template, as the live templates are generally for privileged
users only.
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Post by Michael H. Warfield
That error is generated out of the code, which I authored, that sets up
the autodev device areas and mounts that systemd mandates (but can still
be used by anyone). But, if this is Debian or Ubuntu, what version did
you attempt to install? Unless you're loading a test version, you
shouldn't be getting systemd as your default init system manager (yet).
If you have not explicitly set lxc.autodev = 1 in the config file and
lxc-start does not detect systemd as the init system, you should not
have ventured into that code at all. I'm really baffled how you got in
a situation where you used debootstrap and yet the code is running into
the systemd autodev logic, something I would not have expected for
Ubuntu or Debian just yet (and I don't think those templates are
prepared to set up just yet).
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
Post by Michael H. Warfield
Next question... How did you create your configuration file? That
error message is telling me that either you had lxc.autodev == 1 in the
configuration file OR you're running systemd as your init system
manager. Neither of those should be a particular problem (well, systemd
might if you haven't properly configured certain aspects of the unit
files are startup - but you aren't getting that far) but it's just not
clear how you got where you got doing what you did.
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
Post by Michael H. Warfield
What are the permissions on /home/osmium/.local/share/lxc/osmium ? For
some reason, lxc-start does not have permission to create a symlink in
that directory (or maybe does not have rx read/search permission to all
of its parent directories in the path). That's a short-cut link back to
the hash indexed dev directory under /dev/.lxc/user (for unpriv users)
for the container /dev. Creating that symlink depends only on the
permissions in the path to the directory and the directory itself.
Regards,
Mike
osmium at cadmium:~$ ls -ld /home/osmium/.local/share/lxc/osmium
drwxr-xr-x 3 osmium osmium 4096 Sep 30 15:38
/home/osmium/.local/share/lxc/osmium
osmium at cadmium:~$ ls -ld /home/osmium/.local/share/lxc/osmium/rootfs/
drwxr-xr-x 21 427680 427680 4096 Sep 14 15:56
/home/osmium/.local/share/lxc/osmium/rootfs/
osmium at cadmium:~$ ls -ld /home/osmium/.local/share/lxc/osmium/rootfs/dev
drwxr-xr-x 4 427680 427680 4096 Sep 14 15:56
/home/osmium/.local/share/lxc/osmium/rootfs/dev

osmium at cadmium:~$ grep osmium /etc/sub[ug]id
/etc/subgid:osmium:427680:65536
/etc/subuid:osmium:427680:65536

osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts

Thanks,
Chris
-------------- next part --------------
# Container with network virtualized using a pre-configured bridge named br0 and
lxc.network.type = veth
#lxc.network.veth.pair = osmium
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:73:bd:de
lxc.id_map = u 0 427680 65536
lxc.id_map = g 0 427680 65536

# /var/lib/lxc/escher/config

## Container
lxc.utsname = osmium
lxc.rootfs = /home/osmium/.local/share/lxc/osmium/rootfs
lxc.arch = x86_64
lxc.console = /home/osmium/.console
lxc.tty = 1
lxc.pts = 1024

## Capabilities
lxc.cap.drop = mac_admin
lxc.cap.drop = mac_override
lxc.cap.drop = sys_admin
lxc.cap.drop = sys_module
## Devices
# Allow all devices
#lxc.cgroup.devices.allow = a
# Deny all devices
lxc.cgroup.devices.deny = a
# Allow to mknod all devices (but not using them)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m

# /dev/console
lxc.cgroup.devices.allow = c 5:1 rwm
# /dev/fuse
lxc.cgroup.devices.allow = c 10:229 rwm
# /dev/null
lxc.cgroup.devices.allow = c 1:3 rwm
# /dev/ptmx
lxc.cgroup.devices.allow = c 5:2 rwm
# /dev/pts/*
lxc.cgroup.devices.allow = c 136:* rwm
# /dev/random
lxc.cgroup.devices.allow = c 1:8 rwm
# /dev/rtc
lxc.cgroup.devices.allow = c 254:0 rwm
# /dev/tty
lxc.cgroup.devices.allow = c 5:0 rwm
# /dev/urandom
lxc.cgroup.devices.allow = c 1:9 rwm
# /dev/zero
lxc.cgroup.devices.allow = c 1:5 rwm

## Limits
#lxc.cgroup.cpu.shares = 1024
#lxc.cgroup.cpuset.cpus = 0
#lxc.cgroup.memory.limit_in_bytes = 256M
#lxc.cgroup.memory.memsw.limit_in_bytes = 1G

## Filesystem
lxc.mount.entry = proc /home/osmium/.local/share/lxc/osmium/rootfs/proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry = devpts /home/osmium/.local/share/lxc/osmium/rootfs/dev/pts devpts defaults 0 0
lxc.mount.entry = sysfs /home/osmium/.local/share/lxc/osmium/rootfs/sys sysfs defaults,ro 0 0

-------------- next part --------------
lxc-start 1412095368.928 INFO lxc_start_ui - using rcfile /home/osmium/.local/share/lxc/osmium/config
lxc-start 1412095368.928 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412095368.929 INFO lxc_confile - read uid map: type u nsid 0 hostid 427680 range 65536
lxc-start 1412095368.929 INFO lxc_confile - read uid map: type g nsid 0 hostid 427680 range 65536
lxc-start 1412095368.930 WARN lxc_log - lxc_log_init called with log already initialized
lxc-start 1412095368.930 INFO lxc_lsm - LSM security driver nop
lxc-start 1412095368.930 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412095368.931 DEBUG lxc_conf - allocated pty '/dev/pts/1' (5/6)
lxc-start 1412095368.931 INFO lxc_conf - tty's configured
lxc-start 1412095368.932 DEBUG lxc_start - sigchild handler set
lxc-start 1412095368.932 DEBUG lxc_console - opening /home/osmium/.console for console peer
lxc-start 1412095368.932 DEBUG lxc_console - using '/home/osmium/.console' as console
lxc-start 1412095368.932 DEBUG lxc_console - no console peer
lxc-start 1412095369.212 INFO lxc_start - 'osmium' is initialized
lxc-start 1412095369.243 DEBUG lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1412095369.243 INFO lxc_start - Cloning a new user namespace
lxc-start 1412095369.243 INFO lxc_cgroup - cgroup driver cgroupfs initing for osmium
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.deny' set to 'a'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c *:* m'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'b *:* m'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:1 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 10:229 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 254:0 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm'
lxc-start 1412095369.247 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm'
lxc-start 1412095369.247 INFO lxc_cgfs - cgroup has been setup
lxc-start 1412095369.310 NOTICE lxc_start - switching to gid/uid 0 in new user namespace
lxc-start 1412095369.313 DEBUG lxc_conf - mounted '/home/osmium/.local/share/lxc/osmium/rootfs' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs'
lxc-start 1412095369.314 INFO lxc_conf - 'osmium' hostname has been setup
lxc-start 1412095369.314 DEBUG lxc_conf - mac address '00:16:3e:73:bd:de' on 'eth0' has been setup
lxc-start 1412095369.315 DEBUG lxc_conf - 'eth0' has been setup
lxc-start 1412095369.315 INFO lxc_conf - network has been setup
lxc-start 1412095369.315 DEBUG lxc_conf - Set exec command to /sbin/init
lxc-start 1412095369.324 INFO lxc_conf - Container with systemd init detected - enabling autodev!
lxc-start 1412095369.324 INFO lxc_conf - Mounting /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1412095369.324 DEBUG lxc_conf - entering mount_check_fs for /dev
lxc-start 1412095369.325 DEBUG lxc_conf - mount_check_fs returning 1 last devtmpfs
lxc-start 1412095369.325 INFO lxc_conf - Setup in /dev/.lxc failed. Trying /dev/.lxc/user.
lxc-start 1412095369.325 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
lxc-start 1412095369.325 DEBUG lxc_conf - Bind mounting /dev/.lxc/user/osmium.3c68b3f0c5eeec7d to /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1412095369.325 INFO lxc_conf - Mounted /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1412095369.326 DEBUG lxc_conf - mounted 'proc' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs//proc', type 'proc'
lxc-start 1412095369.326 ERROR lxc_conf - Invalid argument - failed to mount 'devpts' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs//dev/pts'
lxc-start 1412095369.326 ERROR lxc_conf - failed to setup the mount entries for 'osmium'
lxc-start 1412095369.326 ERROR lxc_start - failed to setup the container
lxc-start 1412095369.326 ERROR lxc_sync - invalid sequence number 1. expected 2
lxc-start 1412095369.327 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412095369.419 ERROR lxc_start - failed to spawn 'osmium'
lxc-start 1412095369.420 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412095369.420 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412095369.421 ERROR lxc_start_ui - The container failed to start.
lxc-start 1412095369.421 ERROR lxc_start_ui - Additional information can be obtained by setting the --logfile and --log-priority options.
Michael H. Warfield
2014-09-30 18:28:37 UTC
Permalink
Post by Chris
Post by Michael H. Warfield
Post by Chris
Post by Serge Hallyn
Post by Chris
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
Something will need to set that up. I can't recall offhand
what is supposed to do that. Michael (cc:d), is that done
through the init script?
-serge
That might make sense, as I created this container through
debootstrapping the filesystem into
/home/osmium/.local/share/lxc/osmium/rootfs and then chown/grping all
the files to the appropriate users in this user's subuid/gid range...
pasted below in case anyone finds it useful. Please let me know if there
are further steps required to make this template/container valid.
You created this with debootstrap? So it's an Ubuntu or Debian
container? Why not use the appropriate lxc-create template? They do a
lot of things that you are unlikely to have done. Since you're creating
a container for an unprivileged user, you should probably have used the
download template, as the live templates are generally for privileged
users only.
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
Post by Chris
Post by Michael H. Warfield
That error is generated out of the code, which I authored, that sets up
the autodev device areas and mounts that systemd mandates (but can still
be used by anyone). But, if this is Debian or Ubuntu, what version did
you attempt to install? Unless you're loading a test version, you
shouldn't be getting systemd as your default init system manager (yet).
If you have not explicitly set lxc.autodev = 1 in the config file and
lxc-start does not detect systemd as the init system, you should not
have ventured into that code at all. I'm really baffled how you got in
a situation where you used debootstrap and yet the code is running into
the systemd autodev logic, something I would not have expected for
Ubuntu or Debian just yet (and I don't think those templates are
prepared to set up just yet).
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
Post by Michael H. Warfield
Next question... How did you create your configuration file? That
error message is telling me that either you had lxc.autodev == 1 in the
configuration file OR you're running systemd as your init system
manager. Neither of those should be a particular problem (well, systemd
might if you haven't properly configured certain aspects of the unit
files are startup - but you aren't getting that far) but it's just not
clear how you got where you got doing what you did.
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Post by Chris
Post by Michael H. Warfield
What are the permissions on /home/osmium/.local/share/lxc/osmium ? For
some reason, lxc-start does not have permission to create a symlink in
that directory (or maybe does not have rx read/search permission to all
of its parent directories in the path). That's a short-cut link back to
the hash indexed dev directory under /dev/.lxc/user (for unpriv users)
for the container /dev. Creating that symlink depends only on the
permissions in the path to the directory and the directory itself.
Regards,
Mike
osmium at cadmium:~$ ls -ld /home/osmium/.local/share/lxc/osmium
drwxr-xr-x 3 osmium osmium 4096 Sep 30 15:38
/home/osmium/.local/share/lxc/osmium
osmium at cadmium:~$ ls -ld /home/osmium/.local/share/lxc/osmium/rootfs/
drwxr-xr-x 21 427680 427680 4096 Sep 14 15:56
/home/osmium/.local/share/lxc/osmium/rootfs/
osmium at cadmium:~$ ls -ld /home/osmium/.local/share/lxc/osmium/rootfs/dev
drwxr-xr-x 4 427680 427680 4096 Sep 14 15:56
/home/osmium/.local/share/lxc/osmium/rootfs/dev
osmium at cadmium:~$ grep osmium /etc/sub[ug]id
/etc/subgid:osmium:427680:65536
/etc/subuid:osmium:427680:65536
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!

Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.

Now I see the real problem...

The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.

That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
Post by Chris
Thanks,
Chris
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140930/11109453/attachment-0001.sig>
Chris
2014-09-30 22:56:09 UTC
Permalink
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.

osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
lxc-start: failed to populate /dev in the container
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'osmium'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options

Thanks,
Chris
-------------- next part --------------
lxc-start 1412115865.294 INFO lxc_start_ui - using rcfile /home/osmium/.local/share/lxc/osmium/config
lxc-start 1412115865.294 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412115865.296 INFO lxc_confile - read uid map: type u nsid 0 hostid 427680 range 65536
lxc-start 1412115865.296 INFO lxc_confile - read uid map: type g nsid 0 hostid 427680 range 65536
lxc-start 1412115865.296 WARN lxc_log - lxc_log_init called with log already initialized
lxc-start 1412115865.296 INFO lxc_lsm - LSM security driver nop
lxc-start 1412115865.296 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412115865.298 DEBUG lxc_conf - allocated pty '/dev/pts/1' (5/6)
lxc-start 1412115865.298 INFO lxc_conf - tty's configured
lxc-start 1412115865.298 DEBUG lxc_start - sigchild handler set
lxc-start 1412115865.298 DEBUG lxc_console - opening /home/osmium/.console for console peer
lxc-start 1412115865.298 DEBUG lxc_console - using '/home/osmium/.console' as console
lxc-start 1412115865.298 DEBUG lxc_console - no console peer
lxc-start 1412115865.628 INFO lxc_start - 'osmium' is initialized
lxc-start 1412115865.659 DEBUG lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1412115865.659 INFO lxc_start - Cloning a new user namespace
lxc-start 1412115865.659 INFO lxc_cgroup - cgroup driver cgroupfs initing for osmium
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.deny' set to 'a'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c *:* m'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'b *:* m'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:1 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 10:229 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 254:0 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm'
lxc-start 1412115865.663 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm'
lxc-start 1412115865.663 INFO lxc_cgfs - cgroup has been setup
lxc-start 1412115865.767 NOTICE lxc_start - switching to gid/uid 0 in new user namespace
lxc-start 1412115865.771 DEBUG lxc_conf - mounted '/home/osmium/.local/share/lxc/osmium/rootfs' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs'
lxc-start 1412115865.771 INFO lxc_conf - 'osmium' hostname has been setup
lxc-start 1412115865.772 DEBUG lxc_conf - mac address '00:16:3e:73:bd:de' on 'eth0' has been setup
lxc-start 1412115865.772 DEBUG lxc_conf - 'eth0' has been setup
lxc-start 1412115865.772 INFO lxc_conf - network has been setup
lxc-start 1412115865.772 DEBUG lxc_conf - Set exec command to /sbin/init
lxc-start 1412115865.772 INFO lxc_conf - Container with systemd init detected - enabling autodev!
lxc-start 1412115865.772 INFO lxc_conf - Mounting /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1412115865.772 DEBUG lxc_conf - entering mount_check_fs for /dev
lxc-start 1412115865.773 DEBUG lxc_conf - mount_check_fs returning 1 last devtmpfs
lxc-start 1412115865.773 INFO lxc_conf - Setup in /dev/.lxc failed. Trying /dev/.lxc/user.
lxc-start 1412115865.773 DEBUG lxc_conf - Bind mounting /dev/.lxc/user/osmium.3c68b3f0c5eeec7d to /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1412115865.773 INFO lxc_conf - Mounted /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1412115865.773 DEBUG lxc_conf - mounted 'proc' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs//proc', type 'proc'
lxc-start 1412115865.774 DEBUG lxc_conf - mounted 'sysfs' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs//sys', type 'sysfs'
lxc-start 1412115865.774 INFO lxc_conf - mount points have been setup
lxc-start 1412115865.774 INFO lxc_conf - Creating initial consoles under /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1412115865.774 INFO lxc_conf - Populating /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1412115865.774 ERROR lxc_conf - Operation not permitted - Error creating null
lxc-start 1412115865.774 ERROR lxc_conf - failed to populate /dev in the container
lxc-start 1412115865.774 ERROR lxc_start - failed to setup the container
lxc-start 1412115865.774 ERROR lxc_sync - invalid sequence number 1. expected 2
lxc-start 1412115865.774 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412115865.835 ERROR lxc_start - failed to spawn 'osmium'
lxc-start 1412115865.836 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412115865.836 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1412115865.837 ERROR lxc_start_ui - The container failed to start.
lxc-start 1412115865.837 ERROR lxc_start_ui - Additional information can be obtained by setting the --logfile and --log-priority options.
Michael H. Warfield
2014-09-30 23:39:42 UTC
Permalink
Post by Chris
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.
osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
Ouch. Looks like it's attempting to do a mknod which is not allowed and
can not be allowed as it's prohibited in the kernel to any non-priv
users. That's a security issue that can not be changed. That's going
to be a problem for any autodev containers running under non-priv users.
Serge and/or Stéphane will have to respond to that one.

That was actually a case I was considering when I was discussing the
whole devtmpfs thing with Serge back at LinuxPlumbers last year.
Non-priv users can not create devices (mknod), period, end of
discussion. But they might be able to create hard links to them within
devtmpfs or do bind mounts, which might work under the current setup.
That was the intent at least. I don't recall the hard link device code
being done (though we do bind mounts on some devices) so I'm not sure
what's transpiring at this point in the code.

I'm also not sure about your pts comment above. That's a bind mount as
well (unless you had something else in there). That should also work.
This may be pointing up some underlying problem with getting systemd and
autodev working in a non-priv environment.
Post by Chris
lxc-start: failed to populate /dev in the container
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'osmium'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options
Thanks,
Chris
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140930/31a7439b/attachment.sig>
Michael H. Warfield
2014-10-01 03:54:15 UTC
Permalink
Post by Michael H. Warfield
Post by Chris
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.
osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
Ouch. Looks like it's attempting to do a mknod which is not allowed and
can not be allowed as it's prohibited in the kernel to any non-priv
users. That's a security issue that can not be changed. That's going
to be a problem for any autodev containers running under non-priv users.
Serge and/or Stéphane will have to respond to that one.
That was actually a case I was considering when I was discussing the
whole devtmpfs thing with Serge back at LinuxPlumbers last year.
Non-priv users can not create devices (mknod), period, end of
discussion. But they might be able to create hard links to them within
devtmpfs or do bind mounts, which might work under the current setup.
That was the intent at least. I don't recall the hard link device code
being done (though we do bind mounts on some devices) so I'm not sure
what's transpiring at this point in the code.
Maybe I did test that out last year. IAC... Just retested it. Damn
it, oh yeah... Hardlinks to device nodes in devtmpfs are prohibited to
non-priv users even when permissions would permit. That option is also
non viable. Nice idea. Guess I know why none of us pursued it now.
Post by Michael H. Warfield
I'm also not sure about your pts comment above. That's a bind mount as
well (unless you had something else in there). That should also work.
This may be pointing up some underlying problem with getting systemd and
autodev working in a non-priv environment.
Post by Chris
lxc-start: failed to populate /dev in the container
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'osmium'
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting the
--logfile and --log-priority options
Thanks,
Chris
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140930/33482fcf/attachment.sig>
Serge Hallyn
2014-10-01 13:53:02 UTC
Permalink
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Chris
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.
osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
Ouch. Looks like it's attempting to do a mknod which is not allowed and
can not be allowed as it's prohibited in the kernel to any non-priv
users. That's a security issue that can not be changed. That's going
to be a problem for any autodev containers running under non-priv users.
Serge and/or Stéphane will have to respond to that one.
That was actually a case I was considering when I was discussing the
whole devtmpfs thing with Serge back at LinuxPlumbers last year.
Non-priv users can not create devices (mknod), period, end of
discussion. But they might be able to create hard links to them within
devtmpfs or do bind mounts, which might work under the current setup.
That was the intent at least. I don't recall the hard link device code
being done (though we do bind mounts on some devices) so I'm not sure
what's transpiring at this point in the code.
Maybe I did test that out last year. IAC... Just retested it. Damn
it, oh yeah... Hardlinks to device nodes in devtmpfs are prohibited to
non-priv users even when permissions would permit. That option is also
non viable. Nice idea. Guess I know why none of us pursued it now.
... But that's why we bind mount. Sorry, I've still not dived deeper,
into the code, but something here isn't making sense to me. The
unprivileged user cannot create the /dev/.lxc/user-whatever directory to
which he was trying to symlink, so what should create that? I assume
that in fact you want the persistent container-/dev for an unpriv user
to actually come from ~/.local/share/lxc/container/root.dev ? Then,
yes, inside there when starting the container, for any file which exists
under ~/.local/share/lxc/container/root.dev lxc should bind-mount from
the host's /dev.

-serge
Michael H. Warfield
2014-10-01 14:19:28 UTC
Permalink
Post by Serge Hallyn
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Chris
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.
osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
Ouch. Looks like it's attempting to do a mknod which is not allowed and
can not be allowed as it's prohibited in the kernel to any non-priv
users. That's a security issue that can not be changed. That's going
to be a problem for any autodev containers running under non-priv users.
Serge and/or Stéphane will have to respond to that one.
That was actually a case I was considering when I was discussing the
whole devtmpfs thing with Serge back at LinuxPlumbers last year.
Non-priv users can not create devices (mknod), period, end of
discussion. But they might be able to create hard links to them within
devtmpfs or do bind mounts, which might work under the current setup.
That was the intent at least. I don't recall the hard link device code
being done (though we do bind mounts on some devices) so I'm not sure
what's transpiring at this point in the code.
Maybe I did test that out last year. IAC... Just retested it. Damn
it, oh yeah... Hardlinks to device nodes in devtmpfs are prohibited to
non-priv users even when permissions would permit. That option is also
non viable. Nice idea. Guess I know why none of us pursued it now.
... But that's why we bind mount. Sorry, I've still not dived deeper,
into the code, but something here isn't making sense to me. The
unprivileged user cannot create the /dev/.lxc/user-whatever directory to
which he was trying to symlink, so what should create that?
Actually, he can. /dev/.lxc/user is set up mode 1777 much like /tmp
specifically for that purpose. So an unpriv user gets a
directory /dev/.lxc/user/{container-hash} owned by him and restricted to
him while a priv user gets /dev/.lxc/{container-hash}. That's done in
the startup helper script that set up the parent /dev/.lxc directory.
Post by Serge Hallyn
I assume
that in fact you want the persistent container-/dev for an unpriv user
to actually come from ~/.local/share/lxc/container/root.dev ? Then,
yes, inside there when starting the container, for any file which exists
under ~/.local/share/lxc/container/root.dev lxc should bind-mount from
the host's /dev.
I don't think the autodev populating code currently does bind mounts.
If not, it probably should. Probably should look into that. :-P
Post by Serge Hallyn
-serge
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20141001/6ab252e2/attachment.sig>
Serge Hallyn
2014-10-01 15:05:06 UTC
Permalink
Post by Michael H. Warfield
Post by Serge Hallyn
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Chris
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.
osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
Ouch. Looks like it's attempting to do a mknod which is not allowed and
can not be allowed as it's prohibited in the kernel to any non-priv
users. That's a security issue that can not be changed. That's going
to be a problem for any autodev containers running under non-priv users.
Serge and/or Stéphane will have to respond to that one.
That was actually a case I was considering when I was discussing the
whole devtmpfs thing with Serge back at LinuxPlumbers last year.
Non-priv users can not create devices (mknod), period, end of
discussion. But they might be able to create hard links to them within
devtmpfs or do bind mounts, which might work under the current setup.
That was the intent at least. I don't recall the hard link device code
being done (though we do bind mounts on some devices) so I'm not sure
what's transpiring at this point in the code.
Maybe I did test that out last year. IAC... Just retested it. Damn
it, oh yeah... Hardlinks to device nodes in devtmpfs are prohibited to
non-priv users even when permissions would permit. That option is also
non viable. Nice idea. Guess I know why none of us pursued it now.
... But that's why we bind mount. Sorry, I've still not dived deeper,
into the code, but something here isn't making sense to me. The
unprivileged user cannot create the /dev/.lxc/user-whatever directory to
which he was trying to symlink, so what should create that?
Actually, he can. /dev/.lxc/user is set up mode 1777 much like /tmp
specifically for that purpose. So an unpriv user gets a
Ah, that's what I was trying to ask the other day. So what does that?
Post by Michael H. Warfield
directory /dev/.lxc/user/{container-hash} owned by him and restricted to
him while a priv user gets /dev/.lxc/{container-hash}. That's done in
the startup helper script that set up the parent /dev/.lxc directory.
This is a host init script?
Post by Michael H. Warfield
Post by Serge Hallyn
I assume
that in fact you want the persistent container-/dev for an unpriv user
to actually come from ~/.local/share/lxc/container/root.dev ? Then,
yes, inside there when starting the container, for any file which exists
under ~/.local/share/lxc/container/root.dev lxc should bind-mount from
the host's /dev.
I don't think the autodev populating code currently does bind mounts.
If not, it probably should. Probably should look into that. :-P
Yeah it should be very simple, creat + mount in setup_autodev.
Michael H. Warfield
2014-10-01 15:27:25 UTC
Permalink
Post by Serge Hallyn
Post by Michael H. Warfield
Post by Serge Hallyn
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Chris
Post by Michael H. Warfield
Post by Chris
I haven't looked a whole lot into the premade containers, my gut feeling
was that I didn't want to download a whole operating system from this
project, and that I'd be a lot more comfortable taking distribution that
I trust, and making the template manually. This way I know everything
extra that's going into it.
Our templates are pretty barebones. Very minimal. You'll have to add
just about anything you would really want to make a useful container.
I should definitely take a closer look sometime.
Post by Michael H. Warfield
Post by Chris
It's running Debian Jessie. LXC 1.0.5-3 from package management. And
systemd 208-8 also from package management.
OK... THAT explains a LOT! That systemd option is why you're running
into this problem and you're about to have far worse.
Post by Chris
I took a config from an existing container and modified it for what I
thought would work for an unprivileged container. I've attached the
config for osmium. I've also attached the latest trace output from the
lxc-start, as I've fixed a few slight errors in the config since then.
You're going to have to make some additional changes... Make sure you
add "lxc.kmsg = 0" to your container or systemd.journald is going to eat
your CPU time for lunch (and be sure to flush
your /dev/.lxc/user/osmium* directory). There's also some adjustments
that need to be made for mgetty consoles and such. You also need to
link the shutdown unit to the SIGPWR service to allow lxc to shut the
container down gracefully. You might take a look at the Oracle or
Fedora templates for some guidance there.
Will definitely come back to this once it starts up, thank you for the
advice.
Post by Michael H. Warfield
Post by Chris
osmium at cadmium:~$ find /dev/.lxc/user -ls
9668 0 drwxrwxrwt 3 root root 60 Sep 30 15:38
/dev/.lxc/user
11109 0 drwxr-xr-x 3 427680 427680 60 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d
11110 0 drwxr-xr-x 2 427680 427680 40 Sep 30 15:38
/dev/.lxc/user/osmium.3c68b3f0c5eeec7d/pts
Bingo!
Ok... So it appears that lxc-start did manage to create your dev
directory properly under the host /dev/.lxc/user.
Now I see the real problem...
The same code that creates that directory creates the symlink
in /home/osmium/.local/share/lxc/osmium. But, the /dev/ directory is
owned by "427680:427680" while the directory containing the symlink is
own by "osmium:osmium" and you then have a permission denied because
427680:427680 doesn't have write permissions
to /home/osmium/.local/share/lxc/osmium.
That's a (the!) problem. I'm just not sure if chown/chgrp is the
correct answer or if you need to add some group membership and add group
write permissions with appropriate host auth secondary groups. Either
way, it's that permission problem that biting you in the rear end.
OK, yes. This was that problem. Fixing it has progressed startup a
little further. It didn't like the lxc.mount.entry for devpts, so I
threw that out for the time being also. Now it's still stuck at
'populating dev' though. I've attached the latest trace in case you help
me again.
osmium at cadmium:~$ lxc-start -n osmium -l trace -o /tmp/xxx7
lxc-start: Operation not permitted - Error creating null
Ouch. Looks like it's attempting to do a mknod which is not allowed and
can not be allowed as it's prohibited in the kernel to any non-priv
users. That's a security issue that can not be changed. That's going
to be a problem for any autodev containers running under non-priv users.
Serge and/or Stéphane will have to respond to that one.
That was actually a case I was considering when I was discussing the
whole devtmpfs thing with Serge back at LinuxPlumbers last year.
Non-priv users can not create devices (mknod), period, end of
discussion. But they might be able to create hard links to them within
devtmpfs or do bind mounts, which might work under the current setup.
That was the intent at least. I don't recall the hard link device code
being done (though we do bind mounts on some devices) so I'm not sure
what's transpiring at this point in the code.
Maybe I did test that out last year. IAC... Just retested it. Damn
it, oh yeah... Hardlinks to device nodes in devtmpfs are prohibited to
non-priv users even when permissions would permit. That option is also
non viable. Nice idea. Guess I know why none of us pursued it now.
... But that's why we bind mount. Sorry, I've still not dived deeper,
into the code, but something here isn't making sense to me. The
unprivileged user cannot create the /dev/.lxc/user-whatever directory to
which he was trying to symlink, so what should create that?
Actually, he can. /dev/.lxc/user is set up mode 1777 much like /tmp
specifically for that purpose. So an unpriv user gets a
Ah, that's what I was trying to ask the other day. So what does that?
Post by Michael H. Warfield
directory /dev/.lxc/user/{container-hash} owned by him and restricted to
him while a priv user gets /dev/.lxc/{container-hash}. That's done in
the startup helper script that set up the parent /dev/.lxc directory.
This is a host init script?
More or less, yes. It's lxc-devsetup in /usr/libexec/lxc for systemd
systems and it's a PreExec script for the lxc-containers.service unit.
Since it's only really required for autodev and, todate, we've only been
using autodev for systemd cases (which I understand is about to change)
it was only required in the systemd case. That may need to change if
we're going to be using autodev with upstart or sysvinit.
Post by Serge Hallyn
Post by Michael H. Warfield
Post by Serge Hallyn
I assume
that in fact you want the persistent container-/dev for an unpriv user
to actually come from ~/.local/share/lxc/container/root.dev ? Then,
yes, inside there when starting the container, for any file which exists
under ~/.local/share/lxc/container/root.dev lxc should bind-mount from
the host's /dev.
I don't think the autodev populating code currently does bind mounts.
If not, it probably should. Probably should look into that. :-P
Yeah it should be very simple, creat + mount in setup_autodev.
Pretty much what I figure. Looks like I have a few tweeks to my latest
patch for kmsg with autodev as well (which can not have that symlink
in /dev for systemd or journald wigs out on the CPU). Looks like
Stephane wasn't real thrilled with my earlier patch and the kmsg stuff
in particular, but it's got to be in there for runtime changes.

Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20141001/910c79be/attachment.sig>
Michael H. Warfield
2014-09-30 15:27:52 UTC
Permalink
Post by Serge Hallyn
Post by Chris
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
Something will need to set that up. I can't recall offhand
what is supposed to do that. Michael (cc:d), is that done
through the init script?
No, it should be done in lxc-start from the code in config.c for systemd
when autodev is enabled.

The fact that it's a "permission denied" is saying it's something wrong
in the LXC_PATH to container itself. It's a permission error in there.
Since you can create an arbitrary symlink even if the target does not
exist or you don't have permission to the target, it's got to be from
the location where the symlink is attempted to be created.
Post by Serge Hallyn
-serge
Mike
Post by Serge Hallyn
Post by Chris
Post by Serge Hallyn
Is /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic (or wherever it
sits) setuid-root?
Yes. This was that problem. To my knowledge this program requires
setuid to be at all useful, so I wonder why it's not distributed as
such on Debian/Jessie.
Now my container seems to be running into another issue, it's having
problems populating /dev, I see on the mailing lists that this (or a
very similar) issue cropped up in February, and had since been
patched, so very likely that I'm still doing something wrong. I've
attached the trace level log detailing initialisation of the
container.
lxc-start 1411807327.376 INFO lxc_start_ui - using rcfile /home/osmium/.local/share/lxc/osmium/config
lxc-start 1411807327.399 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807327.420 INFO lxc_confile - read uid map: type u nsid 0 hostid 427680 range 65536
lxc-start 1411807327.420 INFO lxc_confile - read uid map: type g nsid 0 hostid 427680 range 65536
lxc-start 1411807327.420 WARN lxc_log - lxc_log_init called with log already initialized
lxc-start 1411807327.420 INFO lxc_lsm - LSM security driver nop
lxc-start 1411807327.420 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807327.432 DEBUG lxc_conf - allocated pty '/dev/pts/2' (5/6)
lxc-start 1411807327.432 INFO lxc_conf - tty's configured
lxc-start 1411807327.432 DEBUG lxc_start - sigchild handler set
lxc-start 1411807327.432 DEBUG lxc_console - opening /home/osmium/.console for console peer
lxc-start 1411807327.432 DEBUG lxc_console - using '/home/osmium/.console' as console
lxc-start 1411807327.432 DEBUG lxc_console - no console peer
lxc-start 1411807327.776 INFO lxc_start - 'osmium' is initialized
lxc-start 1411807327.807 DEBUG lxc_start - Not dropping cap_sys_boot or watching utmp
lxc-start 1411807327.807 INFO lxc_start - Cloning a new user namespace
lxc-start 1411807327.807 INFO lxc_cgroup - cgroup driver cgroupfs initing for osmium
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.deny' set to 'a'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c *:* m'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'b *:* m'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:1 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 10:229 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 254:0 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm'
lxc-start 1411807327.811 DEBUG lxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm'
lxc-start 1411807327.811 INFO lxc_cgfs - cgroup has been setup
lxc-start 1411807327.932 NOTICE lxc_start - switching to gid/uid 0 in new user namespace
lxc-start 1411807327.935 DEBUG lxc_conf - mounted '/home/osmium/root' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs'
lxc-start 1411807327.935 INFO lxc_conf - 'osmium' hostname has been setup
lxc-start 1411807327.936 DEBUG lxc_conf - mac address '00:16:3e:73:bd:de' on 'eth0' has been setup
lxc-start 1411807327.936 DEBUG lxc_conf - 'eth0' has been setup
lxc-start 1411807327.936 INFO lxc_conf - network has been setup
lxc-start 1411807327.937 DEBUG lxc_conf - Set exec command to /sbin/init
lxc-start 1411807327.952 INFO lxc_conf - Container with systemd init detected - enabling autodev!
lxc-start 1411807327.952 INFO lxc_conf - Mounting /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.952 DEBUG lxc_conf - entering mount_check_fs for /dev
lxc-start 1411807327.952 DEBUG lxc_conf - mount_check_fs returning 1 last devtmpfs
lxc-start 1411807327.952 INFO lxc_conf - Setup in /dev/.lxc failed. Trying /dev/.lxc/user.
lxc-start 1411807327.953 ERROR lxc_conf - Permission denied - WARNING: Failed to create symlink '/home/osmium/.local/share/lxc/osmium/rootfs.dev'->'/dev/.lxc/user/osmium.3c68b3f0c5eeec7d'
lxc-start 1411807327.953 DEBUG lxc_conf - Bind mounting /dev/.lxc/user/osmium.3c68b3f0c5eeec7d to /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1411807327.953 INFO lxc_conf - Mounted /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/proc'
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/dev/pts'
lxc-start 1411807327.953 WARN lxc_conf - ignoring mount point '/home/osmium/sys'
lxc-start 1411807327.953 INFO lxc_conf - mount points have been setup
lxc-start 1411807327.954 INFO lxc_conf - Creating initial consoles under /usr/lib/x86_64-linux-gnu/lxc/rootfs/dev
lxc-start 1411807327.954 INFO lxc_conf - Populating /dev under /usr/lib/x86_64-linux-gnu/lxc/rootfs
lxc-start 1411807327.954 ERROR lxc_conf - Operation not permitted - Error creating null
lxc-start 1411807327.954 ERROR lxc_conf - failed to populate /dev in the container
lxc-start 1411807327.954 ERROR lxc_start - failed to setup the container
lxc-start 1411807327.954 ERROR lxc_sync - invalid sequence number 1. expected 2
lxc-start 1411807327.954 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.067 ERROR lxc_start - failed to spawn 'osmium'
lxc-start 1411807328.068 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.068 INFO lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
lxc-start 1411807328.069 ERROR lxc_start_ui - The container failed to start.
lxc-start 1411807328.069 ERROR lxc_start_ui - Additional information can be obtained by setting the --logfile and --log-priority options.
_______________________________________________
lxc-users mailing list
lxc-users at lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140930/30a2a8d2/attachment.sig>
Continue reading on narkive:
Loading...