Re: PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 24, 2025 at 11:56 AM Windl, Ulrich <u.windl@xxxxxx> 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@xxxxxx> 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
>
>




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux