[SERVER-31814] Log details of process which sent signal (in Linux) Created: 03/Nov/17  Updated: 13/Dec/19  Resolved: 13/Dec/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Billy Donahue
Resolution: Won't Do Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Issue Links:
Related
related to SERVER-33445 Add signal handler to generate stack ... Closed
Sprint: Dev Tools 2019-12-16
Participants:

 Description   

On platforms which support sigwaitinfo() (_POSIX_C_SOURCE >= 199309L), this can be used instead of sigwait() to get information about the process that sent the signal. This is done via the si_pid and si_uid fields of the siginfo_t struct, when si_code indicates that the signal has come from a process (see Signal Actions). Linux is our only supported platform supporting this (sigwaitinfo() man page).

Currently the signalProcessingThread uses sigwait(), but it would be better if it used sigwaitinfo() if possible, and then included some details of the sending process in the "got signal..." log line. At a minimum this would be the pid and uid from the siginfo_t. Even better would be to get some extra info, such as the argv of the pid, and the parent pids, etc (although this would likely involve platform specific code, eg. reading from /proc/pid in Linux). eg. something like:

No sigwaitinfo support (no change)

2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends

Basic info

2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread] got signal 15 (Terminated) from pid 2341 (uid 124), will terminate after current cmd ends

Extended info

2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread] got signal 15 (Terminated) from process:
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread] - pid 2341: uid 0 (root), "kill 20543"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread]   - pid 2340: uid 0 (root), "sudo kill 20543"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread]     - pid 2301: uid 1000 (kev), "-/bin/bash"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread]       - pid 4392: uid 1000 (kev), "sshd: kev@pts/46"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread]         - pid 4381: uid 0 (root), "sshd: kev [priv]"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread]           - pid 1232: uid 0 (root), "/usr/sbin/sshd -D"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread]             - pid 1: uid 0 (root), "/sbin/init"
2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread] will terminate after current cmd ends

When not from a process (eg. ^C in the terminal, for a non-forked server)

2017-10-23T16:50:33.438+1100 I CONTROL  [signalProcessingThread] got signal 15 (Terminated) from kernel, will terminate after current cmd ends



 Comments   
Comment by Billy Donahue [ 13/Dec/19 ]

You will get the top of the tree, though.
For any SI_USER-generated signal, we'll now print the pid and uid available from the sigwaitinfo's siginfo_t result.
We just don't take the further step of digging through /proc and getpwnam to find more details.

So that's not nothing.

Comment by Sara Williamson [ 13/Dec/19 ]

Implementing this took a lot of code and in the end we determined it was too risky at a critical time at a server's lifecycle.

CC billy.donahue

Comment by Billy Donahue [ 22/Nov/19 ]

This is something I need to do as part of SERVER-44379, so assigning to myself for now.

Comment by Andrew Morrow (Inactive) [ 24/Jul/19 ]

Moving this out of the libunwind epic and into Q3 quick wins. It doesn't require libunwind to do this work.

Generated at Thu Feb 08 04:28:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.