3

I know that a SIGINT signal can be raised by the user with Crtl + C or a kill command, but what needs to happen for the system to raise a SIGINT by itself? This question comes to my mind because my system just caught a SIGINT signal while using the read() function in C to read incoming messages in a Unix-like real-time operating system, and it was not user-triggered.

I've been looking on the Internet and I could not find anything related to a system-triggered SIGINT signal, so your help would be more than welcome.

James Worthy
  • 31
  • 2
  • It would be helpful if you specified which operating system you're talking about. Windows? Linux? MacOS? something else entirely? – Felix G Sep 10 '20 at 09:43
  • Sorry, you are right. I am using a Unix-like real-time operating system – James Worthy Sep 10 '20 at 09:48
  • did you close a shell in which your program was running? Or was the system subject to shutdown or restart? – Maximilian Voss Sep 10 '20 at 10:00
  • Nop. My system was running properly and it went to a Failed state due to a SIGINT signal being raised. This signal was raised while the read() function was being executed to read incoming messages. There was no user interaction with the system. – James Worthy Sep 10 '20 at 10:03
  • Do you have the source code of the system, or is it available? – the busybee Sep 10 '20 at 10:05
  • No, sorry, the code is not available :( – James Worthy Sep 10 '20 at 10:06
  • 1
    What does the documentation say for `read()` as you mention it? Can the device that was read trigger the signal? – the busybee Sep 10 '20 at 10:08
  • Thank you for your replies. The function read() is the one from the unistd.h library, so that's the only documentation I have. The message is read from a socket, so it does not seem that the SIGINT signal could be triggered by another device. – James Worthy Sep 10 '20 at 10:30
  • 1
    Can you be a bit more specific. For example which OS exactly do you use? Which syscalls that may cause future signals do call did you use? The signal can come from anywhere and may has nothing to do with `read()`. Is the socket a local or network socket? Was the connection still valid when you received the signal? .... – 12431234123412341234123 Sep 10 '20 at 10:56
  • 1
    If it happens regularly, you could setup a signalhandler with `sigaction()`, set `sa_sigaction` and use `siginfo_t` structure in the signal handler (second argument) to determine the sending process id and more information that could help you finding the cause of the signal. See manpage `sigaction(2)` for more information. – 12431234123412341234123 Sep 10 '20 at 11:05
  • Thanks for your reply. I am using LynxOS. In principle, the only syscall is read() in that case. The connection of the socket was okay at the moment of the failure. I also thought that the issue could have nothing to do with read(), but the code has been running for months and now two failures appeared while executing that function, so I guess something related to read() has to have happened. – James Worthy Sep 10 '20 at 13:02

0 Answers0