Re: bin/57952 (dhcpcd(8) inexplicably terminated in the night)

[Christos Zoulas <christos%zoulas.com@localhost>]

       if (USPACE + ctob(vm->vm_dsize + vm->vm_ssize) >=
            p->p_rlimit[RLIMIT_CORE].rlim_cur) {
                error = EFBIG;          /* better error code? */
                goto release;
        }

Looks like the core resource limit is 0?

christos

> On Feb 23, 2024, at 7:48 PM, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> 
>> Date: Fri, 23 Feb 2024 23:29:05 +0000
>> From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
>> 
>> So I infer that the network proxy must have crashed, in my original
>> case.  But I don't see how to trigger a core dump.
> 
> Just in case somehow there's set-user/group-id processes involved, I
> also tried:
> 
> 1. make /var/chroot/dhcpcd/var/crash owned by _dhcpcd:_dhcpcd
> 2. add `kern.coredump.setid.dump=1' to /etc/modules.conf
> 3. reboot
> 4. kill -ABRT manager
> 
> I got a zero-length core file and a console message;
> 
> [ 1251.6878114] pid 6079 (dhcpcd): system write of 64@0xffffc000b03a79c0 at 0 failed: 27
> 
> I tried unlimiting the file size with
> 
> # sysctl -w proc.$pid.rlimit.filesize.hard=unlimited
> # sysctl -w proc.$pid.rlimit.filesize.soft=unlimited
> 
> and this time, kill -ABRT manager produced a core dump at
> /var/chroot/dhcpcd/var/crash/dhcpcd.core!
> 
> So there's several issues:
> 
> 1. dhcpcd somehow gets the kern.coredump.setid treatment (which I
>   thought was reserved for executables having the set-user/group-id
>   bit set, and I don't see any evidence of that in dhcpcd)
> 
> 2. /var/crash doesn't exist under the chroot, /var/chroot/dhcpcd
> 
> 3. the filesize rlimit prevents the core dump too