[Lxc-users] Problem with core dumps generated from containers, apport

[Hans Feldt]

Thanks great! But what I don't (yet) understand is shouldn't the new %P 
behaviour be the default of %p instead?

I mean a container PID never makes sense in host user space since there 
is a 1:n mapping. Meaning PID x can have n mappings on the host.

Thanks,
Hans

On 04/25/2013 12:23 PM, Stéphane Graber wrote:
> On 04/24/2013 02:10 PM, Hans Feldt wrote:
>>> -----Original Message-----
>>> From: Serge Hallyn [mailto:serge.hallyn at ubuntu.com]
>>> Sent: den 23 april 2013 14:52
>>> To: Hans Feldt
>>> Cc: lxc-users at lists.sourceforge.net
>>> Subject: Re: [Lxc-users] Problem with core dumps generated from
>>> containers, apport
>>
>>>> 260 is the PID of my test program (sleep 1000) in the container. It of
>>>> course had another PID on the host...
>>>
>>> Hm, well that's certainly surprising to me, but there it is, in
>>> fs/coredump.c:format_corename(): case 'p' uses task_tgid_vnr().
>>>
>>> Would you like to send a patch upstream to add 'P' as an option for using the
>>> global pid?
>>
>> Sorry this is out of my competence. I did check the code you pointed at and I think there's
>> a name space conversion thing missing before handing over the PID over to user space. I
>> could not find what function could do the trick.
>>
>> As a workaround if I temporarily change the core_pattern to write to file instead, I
>> should get a readable useable core dump from a container process
>>
>> Thanks,
>> Hans
>
> I've proposed a patch against the upstream kernel which adds a new "%P"
> with the global PID.
>
> This then makes the following core_pattern work on Ubuntu systems:
> |/usr/sbin/chroot /proc/%P/root /usr/share/apport/apport %p %s %c
>
>
> https://lkml.org/lkml/2013/4/24/518
>
>