Hey,
> On 31. Jan 2024, at 16:24, Petr Pisar <ppi...@redhat.com> wrote: > > Key information is code=128. That code is probably si_code member described in > sigaction(2). The manual lists a lot of values as constants. 128 value is > SI_KERNEL according to /usr/include/asm-generic/siginfo.h. It is documented > as "sent by the kernel from somewhere". It means the first signal does not > come a user space. It's genuinly generated by kernel. E.g. when the process is > killed for out-of-memory reason. However, in this case, I would expect kernel > to log this event into dmesg. E.g. out-of-memory killer is very verbose in > dmesg. > > Strange thing is the second line. It reads that process 3211 (code=0 meads > SI_USER, "sent by kill, sigsend, raise") sent SIGKILL to 3257. It's > questionable how a process 3211 killed with the first signal can still emit > signals. A possible explanation is that the signals are procecessed > asychnously and evolution manages to dispatch the signal to bwrap before > kernel > termites evolution because of the first signal. Or I misinterpret the > log. Throwing some ideas out there, is it possible that evolution runs with a seccomp filter or other BPF program configured to kill the process on violation, and that’s what’s happening here? For software that regularly deals with untrusted input, it doesn’t seem unreasonable that the developers might have implemented something like that, and a seccomp kill might actually look like that. -- Clemens Lang RHEL Crypto Team Red Hat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
