Hello Serge, > ... This doesn't show me anything. Can you show the result of: > > mountpoint /proc > ls -l /proc
proc was really not mounted :-)
We found the "problem" in the C library, which caches the value returned by
getpid. So what happens is the working, mounted proc gets unmounted, then
remounted and again unmounted once the container has started. Have a look at
this code:
In utils.c:
int lxc_mount_proc_if_needed(const char *rootfs)
{
...
mypid = getpid();
INFO("I am %d, /proc/self points to \"%s\"", mypid, link);
if (lxc_safe_int(link, &link_to_pid) < 0)
return -1;
/* correct procfs is already mounted */
if (link_to_pid == mypid) <-- 'I am 13379, /proc/self points to "1"'
return 0;
ret = umount2(path, MNT_DETACH); <-- UNMOUNT
if (ret < 0)
WARN("failed to umount \"%s\" with MNT_DETACH", path);
domount:
/* rootfs is NULL */
if (!strcmp(rootfs, ""))
ret = mount("proc", path, "proc", 0, NULL);
else
ret = safe_mount("proc", path, "proc", 0, NULL, rootfs); <--
MOUNT
if (ret < 0)
return -1;
INFO("mounted /proc in container for security transition");
return 1;
}
In conf.c:
int lxc_create_tmp_proc_mount(struct lxc_conf *conf)
{
int mounted;
mounted = lxc_mount_proc_if_needed(conf->rootfs.path ?
conf->rootfs.mount : "");
if (mounted == -1) {
SYSERROR("failed to mount /proc in the container");
/* continue only if there is no rootfs */
if (conf->rootfs.path)
return -1;
} else if (mounted == 1) {
conf->tmp_umount_proc = 1; <-- MARK FOR UNMOUNTING
}
return 0;
}
I wouldn’t consider this a bug, the C library is just very old
(uClibc-0.9.33.2).
Thanks for the support,
Todor
> On 7. Jun 2019, at 18:37, Serge E. Hallyn <se...@hallyn.com> wrote:
>
> On Thu, Jun 06, 2019 at 07:55:04PM +0200, Dr. Todor Dimitrov wrote:
>> Hello,
>>
>> we have an unprivileged container on LXC 2.1.1, which starts without any
>> errors. The /proc system is however not available/mounted:
>>
>> ...
>> drwxr-xr-x 2 root root 1024 Jul 19 2018 proc
>
> ... This doesn't show me anything. Can you show the result of:
>
> mountpoint /proc
> ls -l /proc
>
> ?
>
>> ...
>> dr-xr-xr-x 12 nobody nogroup 0 Jun 6 17:13 sys
>> ...
>>
>> /sys on the other hand is present. The network seems to work, we can login
>> with lxc-console, only commands which rely on /proc are non-functional, e.g.
>> mount, ps, etc. The configuration file contains the following line:
>>
>> lxc.mount.auto = cgroup:rw proc:rw sys:rw
>>
>> The same configuration runs without any problems on a similar system using
>> the same kernel version (3.12.59). Suspicious in the logs are the following
>> entries:
>>
>> lxc-start qivicon 20190606172753.696 DEBUG console -
>> console.c:lxc_console_peer_default:450 - process does not have a controlling
>> terminal
>> lxc-start qivicon 20190606172753.848 INFO lxc_utils -
>> utils.c:lxc_mount_proc_if_needed:1758 - I am 13379, /proc/self points to "1"
>> lxc-start qivicon 20190606172753.848 INFO lxc_utils -
>> utils.c:lxc_mount_proc_if_needed:1780 - mounted /proc in container for
>> security transition
>>
>> On the "working" system, we see:
>>
>> lxc-start qivicon 20190606182855.698 DEBUG console -
>> console.c:lxc_console_peer_default:450 - process does not have a controlling
>> terminal
>> lxc-start qivicon 20190606182855.731 INFO lxc_utils -
>> utils.c:lxc_mount_proc_if_needed:1758 - I am 1, /proc/self points to "1"
>>
>>
>> Do you have any ideas what the cause of the problem might be?
>
> Please post the full logs resulting from lxc-start -l debug -o output_file
>
> -serge
> _______________________________________________
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
