[systemd-devel] [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)

[Mantas Mikulėnas]

On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> wrote:

> >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426
> :
> 161 :
> 60728>:
> >>>> Mantas Mikulenas <grawity at gmail.com> schrieb am 10.02.2022 um 10:34
> in
> > Nachricht
> > <CAPWNY8Wi94qqXUM5gPzuAWS8ffCFk=VeTebZ3vtN_a8M+oJgMw at mail.gmail.com>:
> > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl <
> > > Ulrich.Windl at rz.uni-regensburg.de> 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).

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220210/9cbe930e/attachment.htm>