> On Aug. 14, 2014, 5:47 p.m., Nikita Vetoshkin wrote: > > I don't think that si_uid can give something interesting because it can be > > either 0 or UID of receiving process. How about logging si_pid too? > > Ben Mahler wrote: > si_uid represents the user id of the _sending_ process, not the receiving > process. Am I missing something? > > We could log the pid as well, hopefully that helps us identify long-lived > proceses, like init or monit. > > Nikita Vetoshkin wrote: > >represents the user id of the sending process, not the receiving process. > > I think otherwise you won't receive the signal, sender will get EPERM > upon calling kill(2). > > >that helps us identify long-lived proceses, like init or monit. > > Yes, that's exactly my point. > > Alexandra Sava wrote: > Nikita, please be more specific. Logging or not logging something will > not influence the fact that the signal is delivered or not to the process. > Anyhow, I will log the si_pid since it might be helpful in debugging. > > Nikita Vetoshkin wrote: > I just noted that si_uid can be either 0 or "UID of receiving process", > other values or not possible due to permissions. Thus it is useful, but not > very. That's all. > > Ben Mahler wrote: > Nikita, I'm confused again, you mean UID of the SENDING process, right? > > Alexandra, we should update this per the POSIX documentation: > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html > "On systems not supporting the XSI option, the si_pid and si_uid members > of siginfo_t are only required to be valid when si_code is SI_USER or > SI_QUEUE. On XSI-conforming systems, they are also valid for all si_code > values less than or equal to 0; however, it is unspecified whether SI_USER > and SI_QUEUE have values less than or equal to zero, and therefore XSI > applications should check whether si_code has the value SI_USER or SI_QUEUE > or is less than or equal to 0 to tell whether si_pid and si_uid are valid." > > Nikita Vetoshkin wrote: > Sorry, seems like I'm really having trouble with my communication skills. > What I meant that if we have e.g. mesos slave with UID 1001 - only > processes having UID 0 or UID 1001 can send signals. Attempts from processes > with other UIDs will fail with EPERM. Thus si_uid can be either 0 (root, > which bypasses all checks) and "UID of receiving process" (our UID). > But I'm +1 on squeezing all information about our "killer" :) > > Sorry again for being vague.
Ah I see now, thanks for bringing this up! - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24700/#review50607 ----------------------------------------------------------- On Aug. 18, 2014, 11:33 a.m., Alexandra Sava wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/24700/ > ----------------------------------------------------------- > > (Updated Aug. 18, 2014, 11:33 a.m.) > > > Review request for mesos and Ben Mahler. > > > Bugs: MESOS-1567 > https://issues.apache.org/jira/browse/MESOS-1567 > > > Repository: mesos-git > > > Description > ------- > > Log the user id when receiving a SIGTERM. This will make debugging more easy. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/glog.hpp > 5f763e52a6a3d5a7cb38110ea650283b7a9fa789 > > Diff: https://reviews.apache.org/r/24700/diff/ > > > Testing > ------- > > * make check > * run master binary and send it SIGTERM signal with kill > > > Thanks, > > Alexandra Sava > >
