chronyd not deleting specified pidfile on exit

"Elliott, Robert (Servers)" <[email protected]>
Newsgroups gmane.comp.time.chrony.user
Message-ID <MW5PR84MB1842FF717AF4B6D82116B13EABBE9@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
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-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.