On Thu, Feb 10, 2022 at 3:08 PM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> Mantas Mikulenas <grawity@xxxxxxxxx> schrieb am 10.02.2022 um 12:30 in
Nachricht
<CAPWNY8Ubq4ArBW-uFsjoELO772KT38roaG6RgU=Bkbui4js9Vw@xxxxxxxxxxxxxx>:
> On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl <
> Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>> >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426
>> :
>> 161 :
>> 60728>:
>> >>>> Mantas Mikulenas <grawity@xxxxxxxxx> schrieb am 10.02.2022 um 10:34
>> in
>> > Nachricht
>> > <CAPWNY8Wi94qqXUM5gPzuAWS8ffCFk=VeTebZ3vtN_a8M+oJgMw@xxxxxxxxxxxxxx>:
>> > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl <
>> > > Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>> > >
>> > >> Hi!
>> > >>
>> > >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64)
>> where
>> > >> smartd is restarted for no obvious reason. Support says everything is
>> fine,
>> > >> but I disagree.
>> > >> Specifically smartd.service uses:
>> > >>
>> > >> [Service]
>> > >> Type=notify
>> > >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts
>> > >> ExecStart=/usr/sbin/smartd -n $smartd_opts
>> > >> ExecReload=/bin/kill -HUP $MAINPID
>> > >>
>> > >> And mostly I wonder to what types of changes "notify" does react.
>> > >>
>> > >
>> > > None. It's not an activation mechanism and not a configuration
>> monitoring
>> > > mechanism – it's a readiness indication mechanism.
>> > >
>> > > Type=notify expects the service to send a message to a Unix socket (at
>> > > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some
>> custom
>> > > text to show in 'systemctl status'.)
>> >
>> > Mantas,
>> >
>> > thanks for explaining; obviously I was wrong. But still: How can I find
>> out
>>
>> > why the smartd.service restarts?
>>
>> Hi!
>>
>> I digged further into it:
>> smartd_generate_opts.path has:
>> [Path]
>> Unit=smartd_generate_opts.service
>> PathChanged=/etc/sysconfig/smartmontools
>>
>> smartd_generate_opts.service has:
>> [Service]
>> Type=oneshot
>> ExecStart=/usr/lib/smartmontools/generate_smartd_opts
>>
>> Finally /usr/lib/smartmontools/generate_smartd_opts is not documented.
>>
>> But running that program causes a restart of smartd!
>>
>
> I'm not saying this is complete garbage but ugh.
>
> At least it doesn't seem to be an upstream thing.
>
>
>> The "Change" date was most likely caused by backup software resetting the
>> Access time.
>>
>
> The backup software really ought to start using open(O_NOATIME) and avoid
> having to "reset" anything in the first place...
>
>
>> So back to systemd: What time stamp does it use for PathChanged=?
>>
>
> Technically none – it watches *inotify* events (all except IN_MODIFY).
> Specifically PathChanged= reacts to:
>
> [PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB |
> IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO,
>
> (https://github.com/systemd/systemd/blob/main/src/core/path.c#L37)
>
> So basically a) any kind of rename, delete, attribute change (stuff that
> changes ctime), or b) whenever the file gets *closed* after it has been
> written to (stuff that changes mtime).
Hi!
So a unit using PathChanged= is expected to check again what actually has
changed?
Yes, .path units (not unlike .timer units) only activate another unit but can't inform it of *why* it just got activated.
Doesn't really sound like being useful, as must users probably assume that
"Changed" refers to file content change.
Which is what PathChanged= includes. (The difference between PathChanged and PathModified is that the latter triggers immediately for each individual write (IN_MODIFY), while PathChanged delays the trigger until the file is closed. That makes PathModified the less useful one, in most situations.)
Mantas Mikulėnas
