<div dir="ltr"><div dir="ltr">On Thu, Feb 10, 2022 at 3:08 PM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">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">>>> Mantas Mikulenas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> schrieb am 10.02.2022 um 12:30 in<br>
Nachricht<br>
<CAPWNY8Ubq4ArBW-uFsjoELO772KT38roaG6RgU=<a href="mailto:Bkbui4js9Vw@mail.gmail.com" target="_blank">Bkbui4js9Vw@mail.gmail.com</a>>:<br>
> On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl <<br>
> <a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br>
> <br>
>> >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426<br>
>> :<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<br>
>> 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<br>
>> 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<br>
>> 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>
>><br>
> <br>
> I'm not saying this is complete garbage but ugh.<br>
> <br>
> At least it doesn't seem to be an upstream thing.<br>
> <br>
> <br>
>> The "Change" date was most likely caused by backup software resetting the<br>
>> Access time.<br>
>><br>
> <br>
> The backup software really ought to start using open(O_NOATIME) and avoid<br>
> having to "reset" anything in the first place...<br>
> <br>
> <br>
>> So back to systemd: What time stamp does it use for PathChanged=?<br>
>><br>
> <br>
> Technically none – it watches *inotify* events (all except IN_MODIFY).<br>
> Specifically PathChanged= reacts to:<br>
> <br>
>     [PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB |<br>
> IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO,<br>
> <br>
> (<a href="https://github.com/systemd/systemd/blob/main/src/core/path.c#L37" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/blob/main/src/core/path.c#L37</a>)<br>
> <br>
> So basically a) any kind of rename, delete, attribute change (stuff that<br>
> changes ctime), or b) whenever the file gets *closed* after it has been<br>
> written to (stuff that changes mtime).<br>
<br>
Hi!<br>
<br>
So a unit using PathChanged= is expected to check again what actually has<br>
changed?<br></blockquote><div><br></div><div>Yes, .path units (not unlike .timer units) only activate another unit but can't inform it of *why* it just got activated.</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">
Doesn't really sound like being useful, as must users probably assume that<br>
"Changed" refers to file content change.<br></blockquote><div><br></div><div>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.)</div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Mantas Mikulėnas</div></div></div>