Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-31814

Log details of process which sent signal (in Linux)

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Internal Code
    • Labels:
      None
    • Environment:
      Linux
    • Dev Tools 2019-12-16

      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
      

            Assignee:
            billy.donahue@mongodb.com Billy Donahue
            Reporter:
            kevin.pulo@mongodb.com Kevin Pulo
            Votes:
            5 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: