Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1287062
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: piping core dump to a program escapes container |
| Date | 2015-12-09 04:40 +0100 |
| Message-ID | <qDDLI-2ST-1@gated-at.bofh.it> (permalink) |
| References | <qnf11-4vk-17@gated-at.bofh.it> <qDCPD-2c5-13@gated-at.bofh.it> <qDCZj-2fi-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Dongsheng Yang <yangds.fnst@cn.fujitsu.com> writes: > On 12/09/2015 10:26 AM, Dongsheng Yang wrote: >> On 10/25/2015 05:54 AM, Shayan Pooya wrote: >>> I noticed the following core_pattern behavior in my linux box while >>> running docker containers. I am not sure if it is bug, but it is >>> inconsistent and not documented. >>> >>> If the core_pattern is set on the host, the containers will observe >>> and use the pattern for dumping cores (there is no per cgroup >>> core_pattern). According to core(5) for setting core_pattern one can: >>> >>> 1. echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern >>> 2. echo "|/bin/custom_core /tmp/cores/ %e %p " > >>> /proc/sys/kernel/core_pattern >>> >>> The former pattern evaluates the /tmp/cores path in the container's >>> filesystem namespace. Which means, the host does not see a core file >>> in /tmp/cores. >>> >>> However, the latter evaluates the /bin/custom_core path in the global >>> filesystem namespace. Moreover, if /bin/core decides to write the core >>> to a path (/tmp/cores in this case as shown by the arg to >>> custom_core), the path will be evaluated in the global filesystem >>> namespace as well. >>> >>> The latter behaviour is counter-intuitive and error-prone as the >>> container can fill up the core-file directory which it does not have >>> direct access to (which means the core is also not accessible for >>> debugging if someone only has access to the container). From a container perspective it is perhaps counter intuitive from the perspective of the operator of the machine nothing works specially about core_pattern and it works as designed with no unusual danages. >> Hi Shayan, >> We found the same problem with what you described here. >> Is there any document for this behaviour? I want to know is >> that intentional or as you said a 'bug'. Maybe that's intentional >> to provide a way for admin to collect core dumps from all containers as >> Richard said. I am interested in it too. >> >> Anyone can help here? > > In addition, is that a good idea to make core_pattern to be seperated > in different namespace? The behavior was the best we could do at the time last time this issue was examined. There is enough information available to be able to write a core dumping program that can reliably place your core dumps in your container. There has not yet been an obvious namespace in which to stick core_pattern, and even worse exactly how to appropriate launch a process in a container has not been figured out. If those tricky problems can be solved we can have a core_pattern in a container. What we have now is the best we have been able to figure out so far. Eric > > Yang >> >> Yang >>> >>> Currently, I work around this issue by detecting that the process is >>> crashing from a container (by comparing the namespace pid to the >>> global pid) and refuse to dump the core if it is from a container. >>> >>> Tested on Ubuntu (kernel 3.16) and Fedora (kernel 4.1). >>> -- >>> To unsubscribe from this list: send the line "unsubscribe cgroups" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> . >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: piping core dump to a program escapes container Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-12-09 03:40 +0100
Re: piping core dump to a program escapes container Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-12-09 03:50 +0100
Re: piping core dump to a program escapes container ebiederm@xmission.com (Eric W. Biederman) - 2015-12-09 04:40 +0100
Re: piping core dump to a program escapes container Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-12-09 07:10 +0100
Re: piping core dump to a program escapes container ebiederm@xmission.com (Eric W. Biederman) - 2015-12-09 07:50 +0100
Re: piping core dump to a program escapes container Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-12-09 09:20 +0100
Re: piping core dump to a program escapes container Bruno Prémont <bonbons@linux-vserver.org> - 2015-12-09 09:50 +0100
Re: piping core dump to a program escapes container Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-12-10 01:40 +0100
Re: piping core dump to a program escapes container Dongsheng Yang <yangds.fnst@cn.fujitsu.com> - 2015-12-10 04:10 +0100
csiph-web