应用程序接收神秘的 SIGINT
我们有一个用 C 语言为几个不同的 UNIX 平台编写的小型守护程序应用程序（这个问题发生在 SunOS 5.10 中），它基本上只是打开一个串行端口，然后侦听通过所述端口传入的信息。
在这个特定的实例中，守护进程似乎读取通过串行端口发送的单个传输（例如文件的数据），然后接收 SIGINT。 这种情况每次都会发生。 其他客户使用此设置非常类似，但没有收到 SIGINT。 很明显，用户没有按 Ctrl-C。 我们有一个相对简单的信号处理程序，所以我们肯定知道这就是正在发生的事情。
还有什么可能导致这种情况？ 谷歌搜索并浏览这里的问题，我找不到关于可能导致 SIGINT 的其他事情的太多解释。 我还查看了代码，发现没有调用 raise() ，只有一次调用 Kill(pid, 0) ，无论如何都不会发送 SIGINT 。
任何想法或见解肯定会受到赞赏。
We have a small daemon application written in C for a couple of various UNIX platforms (this problem is happening in SunOS 5.10), that basically just opens up a serial port and then listens for information to come in via said port.
In this particular instance, the daemon appears to read a single transmission (like a file's worth of data) sent over via the serial port, then it receives a SIGINT. This happens every time. Other customers use this setup very similarly without receiving the SIGINT. Quite obviously, the users are NOT pressing Ctrl-C. We have a relatively simple signal handler in place, so we definitely know that that is what is happening.
What else could possibly be causing this? Googling around and looking through the questions here, I couldn't find much explanation as to other things that could cause a SIGINT. I also looked through the code and found no calls to raise() and only a single call to kill(pid, 0) which wouldn't send a SIGINT anyway.
Any thoughts or insight would definitely be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您不希望串行端口成为进程的控制终端，请使用
打开标志O_NOCTTY。 如果是控制终端，来自串口的数据可能会被解释为中断或其他特殊字符。If you do not want the serial port to become the controlling terminal for the process, open it using the
openflagO_NOCTTY. If it is the controlling terminal, data from the serial port may be interpreted as an interrupt or other special character.您没有说明信号处理程序是如何附加的，但是如果您能够使用 sigaction(2) 以便获得
siginfo_t然后看起来会包含发送信号的 pid (si_pid）。You didn't say how your signal handler is attached, but if you're able to attach it using sigaction(2) so as to get a
siginfo_tthen it looks like that would include the pid that sent the signal (si_pid).我发现了一篇有趣的博客文章，内容涉及调试具有类似症状的问题。 虽然我怀疑这是同一个问题，但它有一些非常有用的调试技巧来跟踪信号的起源。
I found an interesting blog post about debugging a problem with similar symptoms. While I doubt it's the same issue, it's got some very useful debugging tips for tracing the origin of signals.