You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Alexandra Sava <al...@gmail.com> on 2014/08/14 17:12:01 UTC

Review Request 24700: Log the user id when receiving a SIGTERM.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/
-----------------------------------------------------------

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
-----

  src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 

Diff: https://reviews.apache.org/r/24700/diff/


Testing
-------


Thanks,

Alexandra Sava


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Alexandra Sava <al...@gmail.com>.

> On Aug. 14, 2014, 5:26 p.m., Ben Mahler wrote:
> > Did you test this manually?

Yes I did. I ran the master and sent it SIGTERM with kill. It worked perfectly fine, I don't know why ReviewBot doesn't like it.


> On Aug. 14, 2014, 5:26 p.m., Ben Mahler wrote:
> > src/logging/logging.cpp, line 75
> > <https://reviews.apache.org/r/24700/diff/1/?file=660530#file660530line75>
> >
> >     Since we're in a signal handler, we have to avoid using system calls that are not async signal safe:
> >     
> >     http://man7.org/linux/man-pages/man7/signal.7.html
> >     
> >     os::user uses sysconf and getpwuid_r, so I think the best we can do here is just print the si_uid.

ok.


- Alexandra


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50600
-----------------------------------------------------------


On Aug. 14, 2014, 3:12 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 3:12 p.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
> -----
> 
>   src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 
> 
> Diff: https://reviews.apache.org/r/24700/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alexandra Sava
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Ben Mahler <be...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50600
-----------------------------------------------------------


Did you test this manually?


src/logging/logging.cpp
<https://reviews.apache.org/r/24700/#comment88470>

    Since we're in a signal handler, we have to avoid using system calls that are not async signal safe:
    
    http://man7.org/linux/man-pages/man7/signal.7.html
    
    os::user uses sysconf and getpwuid_r, so I think the best we can do here is just print the si_uid.


- Ben Mahler


On Aug. 14, 2014, 3:12 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 3:12 p.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
> -----
> 
>   src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 
> 
> Diff: https://reviews.apache.org/r/24700/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alexandra Sava
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Ben Mahler <be...@gmail.com>.

> 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?

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.


- Ben


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50607
-----------------------------------------------------------


On Aug. 14, 2014, 3:12 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 3:12 p.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
> -----
> 
>   src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 
> 
> Diff: https://reviews.apache.org/r/24700/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alexandra Sava
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Ben Mahler <be...@gmail.com>.

> 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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Ben Mahler <be...@gmail.com>.

> 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.

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."


- 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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Alexandra Sava <al...@gmail.com>.

> 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.

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.


- Alexandra


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50607
-----------------------------------------------------------


On Aug. 14, 2014, 3:12 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 3:12 p.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
> -----
> 
>   src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 
> 
> Diff: https://reviews.apache.org/r/24700/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alexandra Sava
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Nikita Vetoshkin <ni...@gmail.com>.

> 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."

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.


- Nikita


-----------------------------------------------------------
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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Nikita Vetoshkin <ni...@gmail.com>.

> 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.

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.


- Nikita


-----------------------------------------------------------
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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Nikita Vetoshkin <ni...@gmail.com>.

> 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.

>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.


- Nikita


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50607
-----------------------------------------------------------


On Aug. 14, 2014, 3:12 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 3:12 p.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
> -----
> 
>   src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 
> 
> Diff: https://reviews.apache.org/r/24700/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alexandra Sava
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Nikita Vetoshkin <ni...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50607
-----------------------------------------------------------


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?

- Nikita Vetoshkin


On Aug. 14, 2014, 3:12 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 3:12 p.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
> -----
> 
>   src/logging/logging.cpp b05a7e0c3cb5fcdf0ffd8ee7e1bb970bf71622ea 
> 
> Diff: https://reviews.apache.org/r/24700/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alexandra Sava
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Ben Mahler <be...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review51472
-----------------------------------------------------------

Ship it!


Ship It!

- Ben Mahler


On Aug. 22, 2014, 1:29 p.m., Alexandra Sava wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24700/
> -----------------------------------------------------------
> 
> (Updated Aug. 22, 2014, 1:29 p.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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Alexandra Sava <al...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/
-----------------------------------------------------------

(Updated Aug. 22, 2014, 1:29 p.m.)


Review request for mesos and Ben Mahler.


Changes
-------

First, check if si_uid and si_pid exist and after that use them.


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 (updated)
-----

  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


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Mesos ReviewBot <de...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review50875
-----------------------------------------------------------


Patch looks great!

Reviews applied: [24700]

All tests passed.

- Mesos ReviewBot


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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Ben Mahler <be...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24700/#review51038
-----------------------------------------------------------



3rdparty/libprocess/3rdparty/stout/include/stout/glog.hpp
<https://reviews.apache.org/r/24700/#comment88915>

    How about:
    
    "Received signal SIGTERM from process %d of user %d; exiting"
    
    Can you add an 'if' condition here based on the POSIX documentation:
    
    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.**


- Ben Mahler


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
> 
>


Re: Review Request 24700: Log the user id when receiving a SIGTERM.

Posted by Alexandra Sava <al...@gmail.com>.
-----------------------------------------------------------
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 (updated)
-----

  3rdparty/libprocess/3rdparty/stout/include/stout/glog.hpp 5f763e52a6a3d5a7cb38110ea650283b7a9fa789 

Diff: https://reviews.apache.org/r/24700/diff/


Testing (updated)
-------

* make check
* run master binary and send it SIGTERM signal with kill 


Thanks,

Alexandra Sava