<div dir="ltr"><div dir="ltr">On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426 :<br>
161 :<br>
60728>:<br>
>>>> Mantas Mikulenas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> schrieb am 10.02.2022 um 10:34 in<br>
> Nachricht<br>
> <CAPWNY8Wi94qqXUM5gPzuAWS8ffCFk=<a href="mailto:VeTebZ3vtN_a8M%2BoJgMw@mail.gmail.com" target="_blank">VeTebZ3vtN_a8M+oJgMw@mail.gmail.com</a>>:<br>
> > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl <<br>
> > <a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br>
> > <br>
> >> Hi!<br>
> >><br>
> >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64)<br>
where<br>
> >> smartd is restarted for no obvious reason. Support says everything is<br>
fine,<br>
> >> but I disagree.<br>
> >> Specifically smartd.service uses:<br>
> >><br>
> >> [Service]<br>
> >> Type=notify<br>
> >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts<br>
> >> ExecStart=/usr/sbin/smartd -n $smartd_opts<br>
> >> ExecReload=/bin/kill -HUP $MAINPID<br>
> >><br>
> >> And mostly I wonder to what types of changes "notify" does react.<br>
> >><br>
> > <br>
> > None. It's not an activation mechanism and not a configuration monitoring<br>
> > mechanism – it's a readiness indication mechanism.<br>
> > <br>
> > Type=notify expects the service to send a message to a Unix socket (at<br>
> > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some<br>
custom<br>
> > text to show in 'systemctl status'.)<br>
> <br>
> Mantas,<br>
> <br>
> thanks for explaining; obviously I was wrong. But still: How can I find out<br>
<br>
> why the smartd.service restarts?<br>
<br>
Hi!<br>
<br>
I digged further into it:<br>
smartd_generate_opts.path has:<br>
[Path]<br>
Unit=smartd_generate_opts.service<br>
PathChanged=/etc/sysconfig/smartmontools<br>
<br>
smartd_generate_opts.service has:<br>
[Service]<br>
Type=oneshot<br>
ExecStart=/usr/lib/smartmontools/generate_smartd_opts<br>
<br>
Finally /usr/lib/smartmontools/generate_smartd_opts is not documented.<br>
<br>
But running that program causes a restart of smartd!<br></blockquote><div><br></div><div>I'm not saying this is complete garbage but ugh.</div><div><br></div><div>At least it doesn't seem to be an upstream thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The "Change" date was most likely caused by backup software resetting the<br>
Access time.<br></blockquote><div><br></div><div>The backup software really ought to start using open(O_NOATIME) and avoid having to "reset" anything in the first place...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So back to systemd: What time stamp does it use for PathChanged=?<br></blockquote><div><br></div><div>Technically none – it watches <i>inotify</i> events (all except IN_MODIFY). Specifically PathChanged= reacts to:</div><div><br></div><div>    [PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB | IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO,<br></div><div><br></div><div>(<a href="https://github.com/systemd/systemd/blob/main/src/core/path.c#L37">https://github.com/systemd/systemd/blob/main/src/core/path.c#L37</a>)<br></div><div><br></div><div>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).</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>