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,
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).
Mantas Mikulėnas
