[chrony-users] chronyd not deleting specified pidfile on exit

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


If running chrony in linux with a specified pidfile:
    pidfile /home/orange/timeperf/chrony-local-run/chrony.pidfile

it does not delete that file when it exits.

Debug logs (with some added prints) show:
$ sudo chronyd -f chrony-local.conf  -d -d
2022-07-04T01:50:01Z util.c:1320:(UTI_OpenFile) Opened chrony-local.conf fd=3 mode=R
2022-07-04T01:50:01Z util.c:1320:(UTI_OpenFile) Opened /home/orange/timeperf/chrony-local-run/chrony.pidfile fd=3 mode=r
2022-07-04T01:50:01Z conf.c:1761:(CNF_CreateDirs) ROB Creating dir=/home/orange/timeperf/chrony-local-run 0770 uid=994 gid=992
2022-07-04T01:50:01Z util.c:1206:(UTI_CheckDirPermissions) ROB buf.st_mode=40750 (octal), uid=994 gid=992
2022-07-04T01:50:01Z util.c:1304:(UTI_OpenFile) Removed /home/orange/timeperf/chrony-local-run/chrony.pidfile
2022-07-04T01:50:01Z util.c:1320:(UTI_OpenFile) Opened /home/orange/timeperf/chrony-local-run/chrony.pidfile fd=3 mode=W
2022-07-04T01:50:01Z util.c:1399:(UTI_DropRoot) Dropped root privileges: UID 994 GID 992
....
2022-07-04T02:14:34Z main.c:105:(delete_pidfile) ROB delete_pidfile Could not access /home/orange/timeperf/chrony-local-run/chrony.pidfile : Permission denied
2022-07-04T02:14:34Z main.c:108:(delete_pidfile) ROB delete_pidfile buf.st_mode=0 (octal), uid=0 gid=0
2022-07-04T02:14:34Z util.c:1368:(UTI_RemoveFile) Could not remove /home/orange/timeperf/chrony-local-run/chrony.pidfile per stat: Permission denied
2022-07-04T02:14:34Z util.c:1373:(UTI_RemoveFile) Could not remove /home/orange/timeperf/chrony-local-run/chrony.pidfile with unlink: Permission denied

vs.
$ sudo chronyd -d -d
2022-07-04T01:48:52Z util.c:1320:(UTI_OpenFile) Opened /etc/chrony.conf fd=3 mode=R
2022-07-04T01:48:52Z util.c:1307:(UTI_OpenFile) Could not open /run/chrony/chronyd.pid : No such file or directory
2022-07-04T01:48:52Z conf.c:1761:(CNF_CreateDirs) ROB Creating dir=/run/chrony 0770 uid=994 gid=992
2022-07-04T01:48:52Z util.c:1206:(UTI_CheckDirPermissions) ROB buf.st_mode=40750 (octal), uid=994 gid=992
2022-07-04T01:48:52Z util.c:1320:(UTI_OpenFile) Opened /run/chrony/chronyd.pid fd=3 mode=W
....
2022-07-04T02:15:18Z main.c:108:(delete_pidfile) ROB delete_pidfile buf.st_mode=100644 (octal), uid=0 gid=0
2022-07-04T01:49:02Z util.c:1377:(UTI_RemoveFile) Removed /run/chrony/chronyd.pid

Both of them create a directory owned by chrony containing a file owned by root:
$ sudo ls -alt chrony-local-run
total 8
drwxr-xr-x. 4 orange orange 4096 Jul  3 21:07 ..
drwxr-x---. 2 chrony chrony   28 Jul  3 21:07 .
-rw-r--r--. 1 root   root      6 Jul  3 21:07 chrony.pidfile

$ sudo ls -alt /run/chrony
total 4
drwxr-x---.  2 chrony chrony   80 Jul  3 21:16 .
-rw-r--r--.  1 root   root      6 Jul  3 21:16 chronyd.pid

The parent of that directory does have different permissions and might
be the reason for the different behavior.

This stat() call is failing:
  /* Avoid logging an error message if the file is not accessible */
  if (stat(path, &buf) < 0) {
    DEBUG_LOG("Could not remove %s per stat: %s", path, strerror(errno));
    return 0;
  }

If I comment out the return, the subsequent unlink() also fails.

The process ID in the file is indeed the process running as chrony:

$ ps -ef | grep chrony
root       44007   41949  0 21:46 pts/0    00:00:00 sudo /home/orange/sw/chrony/chronyd -f chrony-local.conf -d -d
chrony     44008   44007  0 21:46 pts/0    00:00:00 /home/orange/sw/chrony/chronyd -f chrony-local.conf -d -d
$ sudo cat chrony-local-run/chrony.pidfile
44008

Perhaps chronyd should change that file owner from root to the
specified user before dropping root privileges (if -u or user is
enabled), so it can be sure to delete the file later?


--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/