我有一个Linux C ++应用程序，它通过Unix Domain Socket生成并与另一个进程交互。这个新过程基本上只显示当前在任务栏中运行的进程的图标，其中一些菜单项显示在图标中。
问题： 当主应用程序正常关闭时，将删除UDS文件。 但是在应用程序崩溃的情况下，这个UDS文件不会被删除而且会徘徊不前。
有没有办法在应用程序崩溃时通过编码删除UDS文件？
答案 0 :(得分：3)
有没有办法在应用程序崩溃时通过编码删除UDS文件？
是。有几种方法取决于您使用潜在非便携式功能的可行性。
使用单独的流程：
使用单独的流程来监控您的申请;也许是你为此目的写的。当此监视进程检测到您的应用程序已结束时，它会检查Unix域套接字文件。如果找到，则删除它。然后它重新启动应用程序（如果需要）。
使用“抽象套接字”：
我相信你也可以使用“抽象插座”，虽然我自己没有尝试过。
在线linux manual page for the Unix domain socket描述了一个名为“抽象套接字”的扩展。它解释说：“当套接字的所有打开引用都关闭时，抽象套接字会自动消失。”。
使用“封闭式语义”：
基于Linux的Unix domain socket manual page注释部分声称：“通常的UNIX封闭式语义适用;套接字可以随时取消链接，并在最后一次引用它时最终从文件系统中删除”。即调用bind创建套接字，等待客户端连接，然后unlink套接字，然后继续执行可能崩溃的代码。但是，从目录条目中删除套接字后，新的客户端连接尝试将失败。
使用潜在的解决方法
在SO_REUSEADDR来电之前，在套接字上使用bind。这可能允许应用程序重新启动而无需删除套接字。对于Unix套接字，我不知道这种行为是否定义得很好。它可以在一个平台上工作，但不能在另一个平台上工作。
问题：当正常关闭主应用程序时，将删除UDS文件。但是在应用程序崩溃的情况下，这个UDS文件不会被删除而且会徘徊不前。
处理Unix域套接字文件（便携式/标准版）的另一种方法是在创建应用程序之前删除应用程序中的套接字文件。因此，在您的应用程序调用{{1}}之前，它将使用bind。只要它是创建这个文件的唯一过程，事情应该是copacetic w.r.t.避免比赛。
请注意，如果您的应用程序以高权限运行（例如使用set-user-ID功能以root身份运行），则使用unlink可能会打开潜在的安全漏洞。然后确保用户无法告诉应用程序对套接字使用什么路径，并且用户可以修改套接字将驻留的所有目录。否则，用户可以告诉应用程序套接字的完整路径类似unlink并运行它以删除该文件，即使用户自己也没有权限这样做。
这种损害的可能性当然可以通过诸如使用最低权限帐户获得set-user-ID特权或者通过避免set-user-ID一起来缓解。另一个缓解措施是不允许用户指示应用程序使用什么路径来使用它的套接字 - 就像使用硬编码的路径名一样，用户对其任何目录都没有写权限。
答案 1 :(得分：0)
不确定这是否有帮助，但您可以检测和孤立的unix socket。
您可以尝试在启动时锁定文件或套接字。如果锁定成功则意味着套接字是孤立的并且可以被删除。这是因为当进程因任何原因终止时，操作系统会释放文件锁。
或者，bind到该unix套接字。仅当套接字名称未使用时，bind才会成功。