[email protected], le sam. 04 oct. 2025 20:40:23 +0100, a ecrit: > From: Diego Nieto Cid <[email protected]> > > I'm not sure this is the correct approach. The GLIBC manual says abount > SIGLOST: > > It is usually fine to ignore the signal; whatever call was made to > the server that died just returns an error.
Here the daemon explicitly tries to get the signal and reopen the error console. > Sounds like an error response from write with count 0 is actually > an expected result. But here in the case of a SIGLOST, we will get -1, and we are fine with that. There is really not much to test here, better just put (void) to explicit that we don't care about the result. Samuel > -- >8 -- >8 -- > > ../../daemons/runttys.c: In function 'main': > ../../daemons/runttys.c:474:7: warning: ignoring return value of 'write' > declared with attribute 'warn_unused_result' [-Wunused-result] > 474 | write (2, "", 0); > | ^~~~~~~~~~~~~~~~ > --- > daemons/runttys.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/daemons/runttys.c b/daemons/runttys.c > index 4e6b1b4f..212c3e92 100644 > --- a/daemons/runttys.c > +++ b/daemons/runttys.c > @@ -473,7 +473,8 @@ main (void) > /* Elicit a SIGLOST now if the console (on our stderr, i.e. fd 2) has > died. That way, the next error message emitted will actually make > it out to the console if it can be made it work at all. */ > - write (2, "", 0); > + int err = write (2, "", 0); > + assert_backtrace (err == 0); > > /* If a SIGTERM or SIGHUP arrived recently, it set a flag > and broke us out of being blocked in waitpid. */ > -- > 2.51.0
