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

[Mantas Mikulėnas]

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

> >>> Mantas Mikulenas <grawity at gmail.com> schrieb am 10.02.2022 um 12:30 in
> Nachricht
> <CAPWNY8Ubq4ArBW-uFsjoELO772KT38roaG6RgU=Bkbui4js9Vw at mail.gmail.com>:
> > 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).
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220210/a2f2d850/attachment-0001.htm>