Hi guys,
We are working on making core dump behaviour isolated in
container. But the problem is, the /proc/sys/kernel/core_pattern
is a kernel wide setting, not belongs to a container.
So we want to add core_pattern into mnt namespace. What
do you think about it?
Yang
On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
> Hi guys,
> We are working on making core dump behaviour isolated in
> container. But the problem is, the /proc/sys/kernel/core_pattern
> is a kernel wide setting, not belongs to a container.
>
> So we want to add core_pattern into mnt namespace. What
> do you think about it?
Hi Eric,
I found your patch about "net: Implement the per network namespace
sysctl infrastructure", I want to do the similar thing
in mnt namespace. Is that suggested way?
Thanx
Yang
>
> Yang
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
> >Hi guys,
> > We are working on making core dump behaviour isolated in
> >container. But the problem is, the /proc/sys/kernel/core_pattern
> >is a kernel wide setting, not belongs to a container.
> >
> > So we want to add core_pattern into mnt namespace. What
> >do you think about it?
>
> Hi Eric,
> I found your patch about "net: Implement the per network namespace
> sysctl infrastructure", I want to do the similar thing
> in mnt namespace. Is that suggested way?
Why mnt namespace and not something else?
On 12/20/2015 10:37 AM, Al Viro wrote:
> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>> Hi guys,
>>> We are working on making core dump behaviour isolated in
>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>> is a kernel wide setting, not belongs to a container.
>>>
>>> So we want to add core_pattern into mnt namespace. What
>>> do you think about it?
>>
>> Hi Eric,
>> I found your patch about "net: Implement the per network namespace
>> sysctl infrastructure", I want to do the similar thing
>> in mnt namespace. Is that suggested way?
>
> Why mnt namespace and not something else?
Hi Al,
Well, because core_pattern indicates the path to store core file.
In different mnt namespace, we would like to change the path with
different value.
In addition, Let's considering other namespaces:
UTS ns: contains informations of kernel and arch, not proper for
core_pattern.
IPC ns: communication informations, not proper for core_pattern
PID ns: core_pattern is not related with pid
net ns: obviousely no.
user ns: not proper too.
Then I believe it's better to do this in mnt namespace. of course,
core_pattern is just one example. After this infrastructure finished,
we can implement more sysctls as per-mnt if necessary, I think.
Al, what do you think about this idea?
Yang
>
>
> .
>
Dongsheng Yang <[email protected]> writes:
> On 12/20/2015 10:37 AM, Al Viro wrote:
>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>> Hi guys,
>>>> We are working on making core dump behaviour isolated in
>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>> is a kernel wide setting, not belongs to a container.
>>>>
>>>> So we want to add core_pattern into mnt namespace. What
>>>> do you think about it?
>>>
>>> Hi Eric,
>>> I found your patch about "net: Implement the per network namespace
>>> sysctl infrastructure", I want to do the similar thing
>>> in mnt namespace. Is that suggested way?
>>
>> Why mnt namespace and not something else?
>
> Hi Al,
>
> Well, because core_pattern indicates the path to store core file.
> In different mnt namespace, we would like to change the path with
> different value.
>
> In addition, Let's considering other namespaces:
> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
> IPC ns: communication informations, not proper for core_pattern
> PID ns: core_pattern is not related with pid
> net ns: obviousely no.
> user ns: not proper too.
>
> Then I believe it's better to do this in mnt namespace. of course,
> core_pattern is just one example. After this infrastructure finished,
> we can implement more sysctls as per-mnt if necessary, I think.
>
> Al, what do you think about this idea?
The hard part is not the sysctl. The hard part is starting the usermode
helper, in an environment that it can deal with. The mount namespace
really provides you with no help there.
Eric
On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
> Dongsheng Yang <[email protected]> writes:
>
>> On 12/20/2015 10:37 AM, Al Viro wrote:
>>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>>> Hi guys,
>>>>> We are working on making core dump behaviour isolated in
>>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>>> is a kernel wide setting, not belongs to a container.
>>>>>
>>>>> So we want to add core_pattern into mnt namespace. What
>>>>> do you think about it?
>>>>
>>>> Hi Eric,
>>>> I found your patch about "net: Implement the per network namespace
>>>> sysctl infrastructure", I want to do the similar thing
>>>> in mnt namespace. Is that suggested way?
>>>
>>> Why mnt namespace and not something else?
>>
>> Hi Al,
>>
>> Well, because core_pattern indicates the path to store core file.
>> In different mnt namespace, we would like to change the path with
>> different value.
>>
>> In addition, Let's considering other namespaces:
>> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
>> IPC ns: communication informations, not proper for core_pattern
>> PID ns: core_pattern is not related with pid
>> net ns: obviousely no.
>> user ns: not proper too.
>>
>> Then I believe it's better to do this in mnt namespace. of course,
>> core_pattern is just one example. After this infrastructure finished,
>> we can implement more sysctls as per-mnt if necessary, I think.
>>
>> Al, what do you think about this idea?
>
> The hard part is not the sysctl. The hard part is starting the usermode
> helper, in an environment that it can deal with. The mount namespace
> really provides you with no help there.
Do you mean the core dump helper? But I think I don't want to touch it
in my development. I think I can use non-pipe way to get what I want,
Let me try to explain what I want here.
(1). introduce a --core-path option in docker run command to specify the
path in host to store core file in one container.
E.g: docker run --core-path=/core/test --name=test IMAGE
(2). When the container starting, docker attach a volume to it, similar
with "-v /core/test:/var/lib/docker/coredump". That means, the path of
/var/lib/docker/coredump in container is a link to /core/test in host.
(3). Set the /proc/sys/kernel/core_pattern in container as
"/var/lib/docker/coredump". But that should not affect the core_pattern
in host or other containers.
Then I think I can collect the core files from each container and save
them in the paths where I want.
Thanx
Yang
>
> Eric
>
>
>
Dongsheng Yang <[email protected]> writes:
> On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
>> Dongsheng Yang <[email protected]> writes:
>>
>>> On 12/20/2015 10:37 AM, Al Viro wrote:
>>>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>>>> Hi guys,
>>>>>> We are working on making core dump behaviour isolated in
>>>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>>>> is a kernel wide setting, not belongs to a container.
>>>>>>
>>>>>> So we want to add core_pattern into mnt namespace. What
>>>>>> do you think about it?
>>>>>
>>>>> Hi Eric,
>>>>> I found your patch about "net: Implement the per network namespace
>>>>> sysctl infrastructure", I want to do the similar thing
>>>>> in mnt namespace. Is that suggested way?
>>>>
>>>> Why mnt namespace and not something else?
>>>
>>> Hi Al,
>>>
>>> Well, because core_pattern indicates the path to store core file.
>>> In different mnt namespace, we would like to change the path with
>>> different value.
>>>
>>> In addition, Let's considering other namespaces:
>>> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
>>> IPC ns: communication informations, not proper for core_pattern
>>> PID ns: core_pattern is not related with pid
>>> net ns: obviousely no.
>>> user ns: not proper too.
>>>
>>> Then I believe it's better to do this in mnt namespace. of course,
>>> core_pattern is just one example. After this infrastructure finished,
>>> we can implement more sysctls as per-mnt if necessary, I think.
>>>
>>> Al, what do you think about this idea?
>>
>> The hard part is not the sysctl. The hard part is starting the usermode
>> helper, in an environment that it can deal with. The mount namespace
>> really provides you with no help there.
>
> Do you mean the core dump helper? But I think I don't want to touch it
> in my development. I think I can use non-pipe way to get what I want,
> Let me try to explain what I want here.
>
> (1). introduce a --core-path option in docker run command to specify the
> path in host to store core file in one container.
> E.g: docker run --core-path=/core/test --name=test IMAGE
>
> (2). When the container starting, docker attach a volume to it, similar
> with "-v /core/test:/var/lib/docker/coredump". That means, the path of
> /var/lib/docker/coredump in container is a link to /core/test in host.
>
> (3). Set the /proc/sys/kernel/core_pattern in container as
> "/var/lib/docker/coredump". But that should not affect the core_pattern
> in host or other containers.
>
> Then I think I can collect the core files from each container and save
> them in the paths where I want.
For your case that sounds like it would work. Unfortunately for this to
be generally applicable and to let the OS in the contianer control it's
fate the core dump pattern needs to be supported.
Otherwise something clever in userspace that can be written now should
be sufficient to fill the gap. There is enough information for the user
mode helper to implement the policy you would like today.
Eric
On 12/22/2015 05:52 AM, Eric W. Biederman wrote:
> Dongsheng Yang <[email protected]> writes:
>
>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
>>> Dongsheng Yang <[email protected]> writes:
>>>
>>>> On 12/20/2015 10:37 AM, Al Viro wrote:
>>>>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>>>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>>>>> Hi guys,
>>>>>>> We are working on making core dump behaviour isolated in
>>>>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>>>>> is a kernel wide setting, not belongs to a container.
>>>>>>>
>>>>>>> So we want to add core_pattern into mnt namespace. What
>>>>>>> do you think about it?
>>>>>>
>>>>>> Hi Eric,
>>>>>> I found your patch about "net: Implement the per network namespace
>>>>>> sysctl infrastructure", I want to do the similar thing
>>>>>> in mnt namespace. Is that suggested way?
>>>>>
>>>>> Why mnt namespace and not something else?
>>>>
>>>> Hi Al,
>>>>
>>>> Well, because core_pattern indicates the path to store core file.
>>>> In different mnt namespace, we would like to change the path with
>>>> different value.
>>>>
>>>> In addition, Let's considering other namespaces:
>>>> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
>>>> IPC ns: communication informations, not proper for core_pattern
>>>> PID ns: core_pattern is not related with pid
>>>> net ns: obviousely no.
>>>> user ns: not proper too.
>>>>
>>>> Then I believe it's better to do this in mnt namespace. of course,
>>>> core_pattern is just one example. After this infrastructure finished,
>>>> we can implement more sysctls as per-mnt if necessary, I think.
>>>>
>>>> Al, what do you think about this idea?
>>>
>>> The hard part is not the sysctl. The hard part is starting the usermode
>>> helper, in an environment that it can deal with. The mount namespace
>>> really provides you with no help there.
>>
>> Do you mean the core dump helper? But I think I don't want to touch it
>> in my development. I think I can use non-pipe way to get what I want,
>> Let me try to explain what I want here.
>>
>> (1). introduce a --core-path option in docker run command to specify the
>> path in host to store core file in one container.
>> E.g: docker run --core-path=/core/test --name=test IMAGE
>>
>> (2). When the container starting, docker attach a volume to it, similar
>> with "-v /core/test:/var/lib/docker/coredump". That means, the path of
>> /var/lib/docker/coredump in container is a link to /core/test in host.
>>
>> (3). Set the /proc/sys/kernel/core_pattern in container as
>> "/var/lib/docker/coredump". But that should not affect the core_pattern
>> in host or other containers.
>>
>> Then I think I can collect the core files from each container and save
>> them in the paths where I want.
>
> For your case that sounds like it would work. Unfortunately for this to
> be generally applicable and to let the OS in the contianer control it's
> fate the core dump pattern needs to be supported.
>
> Otherwise something clever in userspace that can be written now should
> be sufficient to fill the gap. There is enough information for the user
> mode helper to implement the policy you would like today.
Hi Eric,
To make sure I understand your point correctly：
Do you mean we can write a userspace helper in host such as
/usr/libexec/docker-pipe to get what I want?
Yes, I would say, for my case, it would work. This helper can get the
dump data from containers and dispatch them to different path such
as /var/lib/docker/cores/<ContainerID>/.
But there would be two problems in this solution.
(1). It may affect core dump on host. Normally, other processes in
host would not be happy to use a helper of docker-pipe for themselves.
But host have to share the core_pattern with containers, can't config
it by itself.
(2). If there are some containers don't want to pass the core files
to host, they can't set the core_pattern in this solution.
IMO, we can get core files on host currently, by either non-pipe way I
described above or the pipe way you suggested. But the problem is both
of these methods would affect the core_pattern on host and other
containers.
So, I think the key point here is just isolating the core dump related
sysctl in mnt namespace.
Thanx
Yang
>
> Eric
>
>
> .
>
On 12/22/2015 11:12 AM, Kamezawa Hiroyuki wrote:
> On 2015/12/22 6:52, Eric W. Biederman wrote:
>> Dongsheng Yang <[email protected]> writes:
>>
>>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
>>>> Dongsheng Yang <[email protected]> writes:
>>>>
>>>>> On 12/20/2015 10:37 AM, Al Viro wrote:
>>>>>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>>>>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>>>>>> Hi guys,
>>>>>>>> We are working on making core dump behaviour isolated in
>>>>>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>>>>>> is a kernel wide setting, not belongs to a container.
>>>>>>>>
>>>>>>>> So we want to add core_pattern into mnt namespace. What
>>>>>>>> do you think about it?
>>>>>>>
>>>>>>> Hi Eric,
>>>>>>> I found your patch about "net: Implement the per network namespace
>>>>>>> sysctl infrastructure", I want to do the similar thing
>>>>>>> in mnt namespace. Is that suggested way?
>>>>>>
>>>>>> Why mnt namespace and not something else?
>>>>>
>>>>> Hi Al,
>>>>>
>>>>> Well, because core_pattern indicates the path to store core file.
>>>>> In different mnt namespace, we would like to change the path with
>>>>> different value.
>>>>>
>>>>> In addition, Let's considering other namespaces:
>>>>> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
>>>>> IPC ns: communication informations, not proper for core_pattern
>>>>> PID ns: core_pattern is not related with pid
>>>>> net ns: obviousely no.
>>>>> user ns: not proper too.
>>>>>
>>>>> Then I believe it's better to do this in mnt namespace. of course,
>>>>> core_pattern is just one example. After this infrastructure finished,
>>>>> we can implement more sysctls as per-mnt if necessary, I think.
>>>>>
>>>>> Al, what do you think about this idea?
>>>>
>>>> The hard part is not the sysctl. The hard part is starting the usermode
>>>> helper, in an environment that it can deal with. The mount namespace
>>>> really provides you with no help there.
>>>
>>> Do you mean the core dump helper? But I think I don't want to touch it
>>> in my development. I think I can use non-pipe way to get what I want,
>>> Let me try to explain what I want here.
>>>
>>> (1). introduce a --core-path option in docker run command to specify the
>>> path in host to store core file in one container.
>>> E.g: docker run --core-path=/core/test --name=test IMAGE
>>>
>>> (2). When the container starting, docker attach a volume to it, similar
>>> with "-v /core/test:/var/lib/docker/coredump". That means, the path of
>>> /var/lib/docker/coredump in container is a link to /core/test in host.
>>>
>>> (3). Set the /proc/sys/kernel/core_pattern in container as
>>> "/var/lib/docker/coredump". But that should not affect the core_pattern
>>> in host or other containers.
>>>
>>> Then I think I can collect the core files from each container and save
>>> them in the paths where I want.
>>
>> For your case that sounds like it would work. Unfortunately for this to
>> be generally applicable and to let the OS in the contianer control it's
>> fate the core dump pattern needs to be supported.
>>
>> Otherwise something clever in userspace that can be written now should
>> be sufficient to fill the gap. There is enough information for the user
>> mode helper to implement the policy you would like today.
>>
> Let me clarify my understanding.
>
> 1) running user-mode-helper in a container.
> It's not supported by the kernel. user-mode-helper always works on a host.
>
> 2) running user mode helper in a host.
> It's supported in the newest distro(FC23). (abrt supports container.)
> Summary is here. https://github.com/abrt/abrt/wiki/Containers-and-chroots
>
> If a guest user doesn't want to pass a core to the host owner, core_pattern
> should be configurable but it can't.
Agreed, then we have to make the core_pattern namespace-ed in mnt
namespace.
Thanx
Yang
>
> Thanks,
> -Kame
>
>
>
>
> .
>
Dongsheng Yang <[email protected]> writes:
> On 12/22/2015 05:52 AM, Eric W. Biederman wrote:
>> For your case that sounds like it would work. Unfortunately for this to
>> be generally applicable and to let the OS in the contianer control it's
>> fate the core dump pattern needs to be supported.
>>
>> Otherwise something clever in userspace that can be written now should
>> be sufficient to fill the gap. There is enough information for the user
>> mode helper to implement the policy you would like today.
>
> Hi Eric,
>
> To make sure I understand your point correctly：
> Do you mean we can write a userspace helper in host such as
> /usr/libexec/docker-pipe to get what I want?
>
> Yes, I would say, for my case, it would work. This helper can get the
> dump data from containers and dispatch them to different path such
> as /var/lib/docker/cores/<ContainerID>/.
Yes. And there is enough information present at that time it can
save the core dumpes inside the container the application was
running in.
> But there would be two problems in this solution.
> (1). It may affect core dump on host. Normally, other processes in
> host would not be happy to use a helper of docker-pipe for themselves.
> But host have to share the core_pattern with containers, can't config
> it by itself.
So far figuring out how to share the core dump helper appears simpler
than fixing user mode helper.
> (2). If there are some containers don't want to pass the core files
> to host, they can't set the core_pattern in this solution.
Again so far fixing that in user space appears to be more tractable
and easier than anything that has been proposed kernel side.
> IMO, we can get core files on host currently, by either non-pipe way I
> described above or the pipe way you suggested. But the problem is both
> of these methods would affect the core_pattern on host and other
> containers.
>
> So, I think the key point here is just isolating the core dump related
> sysctl in mnt namespace.
You don't have to convince me it would be nice to do. You have to
convince me it is practical to implement. Which is an entirely
different problem.
Given the other constraints on an implementation the pid namespace looks
by far the one best suited to host such a sysctl if it is possible to
implement safely.
Eric
On 2015/12/20 18:47, Eric W. Biederman wrote:
> Dongsheng Yang <[email protected]> writes:
>
>> On 12/20/2015 10:37 AM, Al Viro wrote:
>>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>>> Hi guys,
>>>>> We are working on making core dump behaviour isolated in
>>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>>> is a kernel wide setting, not belongs to a container.
>>>>>
>>>>> So we want to add core_pattern into mnt namespace. What
>>>>> do you think about it?
>>>>
>>>> Hi Eric,
>>>> I found your patch about "net: Implement the per network namespace
>>>> sysctl infrastructure", I want to do the similar thing
>>>> in mnt namespace. Is that suggested way?
>>>
>>> Why mnt namespace and not something else?
>>
>> Hi Al,
>>
>> Well, because core_pattern indicates the path to store core file.
>> In different mnt namespace, we would like to change the path with
>> different value.
>>
>> In addition, Let's considering other namespaces:
>> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
>> IPC ns: communication informations, not proper for core_pattern
>> PID ns: core_pattern is not related with pid
>> net ns: obviousely no.
>> user ns: not proper too.
>>
>> Then I believe it's better to do this in mnt namespace. of course,
>> core_pattern is just one example. After this infrastructure finished,
>> we can implement more sysctls as per-mnt if necessary, I think.
>>
>> Al, what do you think about this idea?
>
> The hard part is not the sysctl. The hard part is starting the usermode
> helper, in an environment that it can deal with. The mount namespace
> really provides you with no help there.
>
Let me ask. I think user-mode-helper shouldn be found in container's namespace.
Or Do you mean running user-mode-helper out of a container ?
I think if a user need to send cores to outside of a container, a file descriptor
or a network end point should be able to be passed to sysctl.
Thanks,
-Kame
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 2015/12/22 6:52, Eric W. Biederman wrote:
> Dongsheng Yang <[email protected]> writes:
>
>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
>>> Dongsheng Yang <[email protected]> writes:
>>>
>>>> On 12/20/2015 10:37 AM, Al Viro wrote:
>>>>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>>>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
>>>>>>> Hi guys,
>>>>>>> We are working on making core dump behaviour isolated in
>>>>>>> container. But the problem is, the /proc/sys/kernel/core_pattern
>>>>>>> is a kernel wide setting, not belongs to a container.
>>>>>>>
>>>>>>> So we want to add core_pattern into mnt namespace. What
>>>>>>> do you think about it?
>>>>>>
>>>>>> Hi Eric,
>>>>>> I found your patch about "net: Implement the per network namespace
>>>>>> sysctl infrastructure", I want to do the similar thing
>>>>>> in mnt namespace. Is that suggested way?
>>>>>
>>>>> Why mnt namespace and not something else?
>>>>
>>>> Hi Al,
>>>>
>>>> Well, because core_pattern indicates the path to store core file.
>>>> In different mnt namespace, we would like to change the path with
>>>> different value.
>>>>
>>>> In addition, Let's considering other namespaces:
>>>> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
>>>> IPC ns: communication informations, not proper for core_pattern
>>>> PID ns: core_pattern is not related with pid
>>>> net ns: obviousely no.
>>>> user ns: not proper too.
>>>>
>>>> Then I believe it's better to do this in mnt namespace. of course,
>>>> core_pattern is just one example. After this infrastructure finished,
>>>> we can implement more sysctls as per-mnt if necessary, I think.
>>>>
>>>> Al, what do you think about this idea?
>>>
>>> The hard part is not the sysctl. The hard part is starting the usermode
>>> helper, in an environment that it can deal with. The mount namespace
>>> really provides you with no help there.
>>
>> Do you mean the core dump helper? But I think I don't want to touch it
>> in my development. I think I can use non-pipe way to get what I want,
>> Let me try to explain what I want here.
>>
>> (1). introduce a --core-path option in docker run command to specify the
>> path in host to store core file in one container.
>> E.g: docker run --core-path=/core/test --name=test IMAGE
>>
>> (2). When the container starting, docker attach a volume to it, similar
>> with "-v /core/test:/var/lib/docker/coredump". That means, the path of
>> /var/lib/docker/coredump in container is a link to /core/test in host.
>>
>> (3). Set the /proc/sys/kernel/core_pattern in container as
>> "/var/lib/docker/coredump". But that should not affect the core_pattern
>> in host or other containers.
>>
>> Then I think I can collect the core files from each container and save
>> them in the paths where I want.
>
> For your case that sounds like it would work. Unfortunately for this to
> be generally applicable and to let the OS in the contianer control it's
> fate the core dump pattern needs to be supported.
>
> Otherwise something clever in userspace that can be written now should
> be sufficient to fill the gap. There is enough information for the user
> mode helper to implement the policy you would like today.
>
Let me clarify my understanding.
1) running user-mode-helper in a container.
It's not supported by the kernel. user-mode-helper always works on a host.
2) running user mode helper in a host.
It's supported in the newest distro(FC23). (abrt supports container.)
Summary is here. https://github.com/abrt/abrt/wiki/Containers-and-chroots
If a guest user doesn't want to pass a core to the host owner, core_pattern
should be configurable but it can't.
Thanks,
-Kame