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

[Mantas Mikulėnas <grawity@xxxxxxxxx>]

On Fri, Jan 24, 2025 at 10: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:

The backup software should learn to open files with O_NOATIME...

 

# 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=?

I think that's what PathChanged= is documented to do, it reacts to all inotify events that indicate a change, including IN_ATTRIB – not specifically "contents".

--

Mantas Mikulėnas