[systemd-devel] PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Andrei Borzenkov
arvidjaar at gmail.com
Fri Jan 24 09:12:11 UTC 2025
On Fri, Jan 24, 2025 at 11:56 AM Windl, Ulrich <u.windl at ukr.de> wrote:
>
> Hi!
>
>
>
> Debugging some backup issue I noticed that systemd announced “Starting Update system wide CA certificates...” multiple times during backup.
>
> As I was sure no new certificates were installed I checked the unit; it contains:
>
> # /usr/lib/systemd/system/ca-certificates.path
>
> [Unit]
>
> Description=Watch for changes in CA certificates
>
> After=local-fs.target
>
>
>
> [Path]
>
> Unit=ca-certificates.service
>
> PathExists=/etc/pki/trust/.updated
>
> PathChanged=/usr/share/pki/trust
>
> PathChanged=/usr/share/pki/trust/anchors
>
> PathChanged=/usr/share/pki/trust/blacklist
>
> PathChanged=/etc/pki/trust
>
> PathChanged=/etc/pki/trust/anchors
>
> PathChanged=/etc/pki/trust/blacklist
>
>
>
> [Install]
>
> WantedBy=default.target
>
> When checking all the directories, I found no “change” there, but (old bug!):
>
> The backup software tried to reset the file’s access time after backing up a file, so the inode modification time will be changed. Like this:
>
> # stat /etc/pki/trust/blacklist/
>
> File: /etc/pki/trust/blacklist/
>
> Size: 0 Blocks: 0 IO Block: 4096 directory
>
> Device: 23h/35d Inode: 15384 Links: 1
>
> Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
>
> Access: 2025-01-24 09:44:43.086125631 +0100
>
> Modify: 2024-04-17 17:00:10.000000000 +0200
>
> Change: 2025-01-24 09:44:42.974123978 +0100
>
> Birth: 2024-11-12 09:04:58.891998036 +0100
>
>
>
> So the directory was not modified in the sense of a content change.
>
systemd watches for IN_ATTRIB which includes metadata change and it
has been this way from the very beginning (or at least very close to
it).
> I wonder: Is systemd doing “the correct thing” for PathChanged=?
>
The documentation most certainly make simpression that only changes to
the file content matter:
"It is not activated on every write to the watched file but it is
activated if the file which was open for writing gets closed."
> Note: the access time being newer than the change time is probably due to the effect of either running the unit, or me chacking the dates.
>
>
>
> Kind regards,
>
> Ulrich Windl
>
>
On Fri, Jan 24, 2025 at 11:56 AM Windl, Ulrich <u.windl at ukr.de> wrote:
>
> Hi!
>
>
>
> Debugging some backup issue I noticed that systemd announced “Starting Update system wide CA certificates...” multiple times during backup.
>
> As I was sure no new certificates were installed I checked the unit; it contains:
>
> # /usr/lib/systemd/system/ca-certificates.path
>
> [Unit]
>
> Description=Watch for changes in CA certificates
>
> After=local-fs.target
>
>
>
> [Path]
>
> Unit=ca-certificates.service
>
> PathExists=/etc/pki/trust/.updated
>
> PathChanged=/usr/share/pki/trust
>
> PathChanged=/usr/share/pki/trust/anchors
>
> PathChanged=/usr/share/pki/trust/blacklist
>
> PathChanged=/etc/pki/trust
>
> PathChanged=/etc/pki/trust/anchors
>
> PathChanged=/etc/pki/trust/blacklist
>
>
>
> [Install]
>
> WantedBy=default.target
>
> When checking all the directories, I found no “change” there, but (old bug!):
>
> The backup software tried to reset the file’s access time after backing up a file, so the inode modification time will be changed. Like this:
>
> # stat /etc/pki/trust/blacklist/
>
> File: /etc/pki/trust/blacklist/
>
> Size: 0 Blocks: 0 IO Block: 4096 directory
>
> Device: 23h/35d Inode: 15384 Links: 1
>
> Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
>
> Access: 2025-01-24 09:44:43.086125631 +0100
>
> Modify: 2024-04-17 17:00:10.000000000 +0200
>
> Change: 2025-01-24 09:44:42.974123978 +0100
>
> Birth: 2024-11-12 09:04:58.891998036 +0100
>
>
>
> So the directory was not modified in the sense of a content change.
>
> I wonder: Is systemd doing “the correct thing” for PathChanged=?
>
> Note: the access time being newer than the change time is probably due to the effect of either running the unit, or me chacking the dates.
>
>
>
> Kind regards,
>
> Ulrich Windl
>
>
More information about the systemd-devel
mailing list