我有一个deamon，一次只能运行一个实例。 守护进程是更大的应用程序的一部分。 我是这样做的：
O_CREAT | O_RDWR open() /tmp/prog.pid O_CREAT | O_RDWR ，权限0666.权限实际上变成了0664，可能是因为umask（？） flock()在由open()返回的文件描述符上，用LOCK_EX | LOCK_NB LOCK_EX | LOCK_NB 这是我所有的第一。 我的守护进程在SIGTERM和SIGINT上退出，但事实certificate，退出时锁没有被释放。 我在man 1 flock帮助下实现了（奇怪的是不是在第二man 2 flock ），如果“所附的指挥小组可能已经分派了一个不应该持有锁的后台进程”，则可能需要手动解锁。 这是因为我正在开发一个守护进程，所以我现在在退出时手动解锁。
现在到我的问题：有几个用户可能正在运行守护进程。
如果user1正在运行守护进程，我希望user2能够杀死它并以自己的身份重新启动它。
locking的文件/tmp/prog.pid拥有权限/tmp/prog.pid ，所有者user1，组user1。
停止脚本prog_stop杀死了应用程序中涉及的所有进程（它需要超级用户权限，我确定）。 它也杀死守护进程。 当user2运行prog_stop ，锁被释放（我相信），但是user2 不能启动它自己的守护进程 ，因为它既不是锁文件的所有者，也不是它的组。
几种可能的解决方
newgrp 。 容易忘记，不容易执行，人们这样做。 可能在用于启动应用程序的脚本中设置当前组？ prog_stop的locking文件。 缺点：我从C文件中打开文件，其中定义了pathstring。 我需要在停止脚本中写入（并保持！）与path完全相同的文件名。 守护进程的locking文件必须非常普遍。 处理这个问题的标准方法是什么？
锁文件的标准方法是将守护进程转换为服务，并要求sudo （或通过其他方式成为root ）来启动和停止它。
现在你可以给文件一个特定的组; 这个组中的用户可以修改它。 他们可以使用newgrp但最好使用usermod --append --groups=foo bar （将用户bar添加到组foo ;用户保留其原始GID以及所有其他组）。 重新登录后，您可以使用id bar进行验证。
这是非常乏味的。 当我需要这样的东西时，我创建一个套接字。 套接字与创建它们的进程一起被杀死（所以不需要清理）。 套接字也可以用来与正在运行的守护进程进行通信（给我你的状态，关机，甚至重启，…）。
我正在使用一个默认端口号，我编译到应用程序，但我也使用环境变量来覆盖默认值。
只要确保你创建一个侦听localhost的套接字; 否则互联网上的任何人都可以与之通话。