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]