Hi,
Alex has tried to pick up the package, but he is being told the supplied tracking number is not valid it should be 12 digits.
Are you able to provide a copy of the shipping label or anything similar and can you confirm the address it was being sent to.
Mark
Saunders
Principal Service Operations Engineer
T: +442475269513
M: +447764305680
E: Mark.Saunders@xxxxxxxxxx
Click here to send me something sensitive or securely!
-----Original Message-----
From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx
Sent: 24 January 2025 10:03
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: systemd-devel Digest, Vol 177, Issue 26
*** Warning: This email originated from outside of Flooid’s email system. DO NOT CLICK LINKS or ATTACHMENTS in this email unless you recognise the sender and know the content is safe. ***
Send systemd-devel mailing list submissions to
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
or, via email, send a message with subject or body 'help' to
systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
systemd-devel-owner@xxxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than "Re: Contents of systemd-devel digest..."
Today's Topics:
1. PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of
SLES15 SP6 (Windl, Ulrich)
2. Re: systemd-devel] systemd-devel] dbus-broker can be used
for a "user" type bus accessible over tcp or not? (Erik Slagter)
3. Re: PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of
SLES15 SP6 (Andrei Borzenkov)
4. Re: PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of
SLES15 SP6 (Mantas Mikul?nas)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Jan 2025 08:56:42 +0000
From: "Windl, Ulrich" <u.windl@xxxxxx>
To: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: PathChanged= in
systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Message-ID: <725de1815be041b8bd497e793e8b19ed@xxxxxx>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250124/925947a1/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 24 Jan 2025 10:10:03 +0100
From: Erik Slagter <erik@xxxxxxxxxxxx>
To: Cristian Rodr?guez <crrodriguez@xxxxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: systemd-devel] systemd-devel] dbus-broker
can be used for a "user" type bus accessible over tcp or not?
Message-ID: <44300e69-18f3-42bd-ac95-82ad49e68019@xxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 21-01-2025 15:34, Cristian Rodr?guez wrote:
> On Tue, Jan 21, 2025 at 6:05?AM Erik Slagter <erik@xxxxxxxxxxxx> wrote:
>
>> So now we have wavered all responsibilities. Is it possible or is it
>> not possible? Dbus-broker listening on tcp? If it's not possible, my
>> question is answered and I can go move on.
>
> Come on..if you do that just configure stunnel to do what you want
> with PSK auth. it supports all sorts of sockets and provides you with
> the minimal security you need.
Please note, as I find out yesterday: remote access to a dbus can work using socat, probably using stunnel as well. Stunnel would add the advantage of encryption BUT it doesn't help for authentication.
Apparently the authentication of dbus itself also "works" remotely. It appears the authentication cookie sent by the remote client can only be validated (and accepted) when the user id is equal between the remote client and socat (or stunnel) running locally. Still not as secure as a local dbus, but it's not that just everyone can connect.
------------------------------
Message: 3
Date: Fri, 24 Jan 2025 12:12:11 +0300
From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
To: "Windl, Ulrich" <u.windl@xxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: PathChanged= in
systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Message-ID:
<CAA91j0UrWjYrrkSo-Q+4TpTAViOaTq_bRvDY-J+-v_vuD=2nCw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
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
>
>
------------------------------
Message: 4
Date: Fri, 24 Jan 2025 12:02:52 +0200
From: Mantas Mikul?nas <grawity@xxxxxxxxx>
To: "Windl, Ulrich" <u.windl@xxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: PathChanged= in
systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Message-ID:
<CAPWNY8W-TxjJW3Gk3WZcmHM=D4ffmWZ85FF0HzTPmG-kP_RHMw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250124/9bee6b6c/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
------------------------------
End of systemd-devel Digest, Vol 177, Issue 26
**********************************************
Alex has tried to pick up the package, but he is being told the supplied tracking number is not valid it should be 12 digits.
Are you able to provide a copy of the shipping label or anything similar and can you confirm the address it was being sent to.
Mark
Saunders
Principal Service Operations Engineer
T: +442475269513
M: +447764305680
E: Mark.Saunders@xxxxxxxxxx
Click here to send me something sensitive or securely!
|
From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx
Sent: 24 January 2025 10:03
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: systemd-devel Digest, Vol 177, Issue 26
*** Warning: This email originated from outside of Flooid’s email system. DO NOT CLICK LINKS or ATTACHMENTS in this email unless you recognise the sender and know the content is safe. ***
Send systemd-devel mailing list submissions to
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
or, via email, send a message with subject or body 'help' to
systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
systemd-devel-owner@xxxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than "Re: Contents of systemd-devel digest..."
Today's Topics:
1. PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of
SLES15 SP6 (Windl, Ulrich)
2. Re: systemd-devel] systemd-devel] dbus-broker can be used
for a "user" type bus accessible over tcp or not? (Erik Slagter)
3. Re: PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of
SLES15 SP6 (Andrei Borzenkov)
4. Re: PathChanged= in systemd-254.21-150600.4.21.1.x86_64 of
SLES15 SP6 (Mantas Mikul?nas)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Jan 2025 08:56:42 +0000
From: "Windl, Ulrich" <u.windl@xxxxxx>
To: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: PathChanged= in
systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Message-ID: <725de1815be041b8bd497e793e8b19ed@xxxxxx>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250124/925947a1/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 24 Jan 2025 10:10:03 +0100
From: Erik Slagter <erik@xxxxxxxxxxxx>
To: Cristian Rodr?guez <crrodriguez@xxxxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: systemd-devel] systemd-devel] dbus-broker
can be used for a "user" type bus accessible over tcp or not?
Message-ID: <44300e69-18f3-42bd-ac95-82ad49e68019@xxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 21-01-2025 15:34, Cristian Rodr?guez wrote:
> On Tue, Jan 21, 2025 at 6:05?AM Erik Slagter <erik@xxxxxxxxxxxx> wrote:
>
>> So now we have wavered all responsibilities. Is it possible or is it
>> not possible? Dbus-broker listening on tcp? If it's not possible, my
>> question is answered and I can go move on.
>
> Come on..if you do that just configure stunnel to do what you want
> with PSK auth. it supports all sorts of sockets and provides you with
> the minimal security you need.
Please note, as I find out yesterday: remote access to a dbus can work using socat, probably using stunnel as well. Stunnel would add the advantage of encryption BUT it doesn't help for authentication.
Apparently the authentication of dbus itself also "works" remotely. It appears the authentication cookie sent by the remote client can only be validated (and accepted) when the user id is equal between the remote client and socat (or stunnel) running locally. Still not as secure as a local dbus, but it's not that just everyone can connect.
------------------------------
Message: 3
Date: Fri, 24 Jan 2025 12:12:11 +0300
From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
To: "Windl, Ulrich" <u.windl@xxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: PathChanged= in
systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Message-ID:
<CAA91j0UrWjYrrkSo-Q+4TpTAViOaTq_bRvDY-J+-v_vuD=2nCw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
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
>
>
------------------------------
Message: 4
Date: Fri, 24 Jan 2025 12:02:52 +0200
From: Mantas Mikul?nas <grawity@xxxxxxxxx>
To: "Windl, Ulrich" <u.windl@xxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: PathChanged= in
systemd-254.21-150600.4.21.1.x86_64 of SLES15 SP6
Message-ID:
<CAPWNY8W-TxjJW3Gk3WZcmHM=D4ffmWZ85FF0HzTPmG-kP_RHMw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250124/9bee6b6c/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
------------------------------
End of systemd-devel Digest, Vol 177, Issue 26
**********************************************
