Samuel Sieb wrote:
> On 02/03/2018 05:57 PM, Todd Zullinger wrote:
>> The unit tasks are logged, so you can see them with
>> journalctl or in syslog.  (Not that it's at all ideal to
>> have to look around to find what may have caused this
>> less-than-useful output.)
> 
> How is it not useful?  I'm happy to be aware of that part of the
> transaction.  It would certainly be more useful if there was some indication
> of what specifically it was for.

IMO, it's not useful because it tells the user nothing about
what script is actually running.

What useful information is included in:

  Running as unit: run-re2635381e8fe44a6aad4926eddab6961.service

It says that something is running, but no detail about what
it is.  If more scriptlets add similar calls to systemd-run,
then we'll just have more of those lines, none of which
allow a user to do anything without digging into the logs to
see what service was actually run.  And since the
information is already in the logs, sending the least useful
part of it to stdout during the rpm transaction is not of
any real value.

This is similar to enabling or starting a service in %post.
The output from systemctl start (or /sbin/service, from way
back) isn't sent to stdout either.  Scriptlets are not
supposed to be noisy.

>> The man-db-cache-update service checks /etc/sysconfig/man-db
>> and if the variable SERVICE is not 'no' it runs.  So it
>> should be possible to disable this proactive updating of the
>> man-db if desired.
> 
> This mandb run has always been done.  The change now to running it as a
> service is because when it was being run as part of the main process, it was
> taking a very long time sometimes and holding up the rest of the
> transaction.  Now, it's running separately and is not waited for.

Sure, I understand that part.  I still don't think there's
any value to leaving the systemd-run output in the
transaction output.

> Personally, I hope it's not accepted and I expect there are other parts that
> are using or will use this method.

I'm genuinely curious what value you see in having these
"Running as unit: run-*.service" lines in the output.

I can see wanting to know what was happening if one of them
hangs or causes errors, but the way this is currently done,
the only error output we'd see is if the systemd-run call
itself failed.  I care more about error output of any
commands which are run as scriptlets, but the output of the
systemd service is sent to the logs rather than the terminal
already, so I have to look there for output and errors.

All I see in the case of the man-db-cache-update scriptlet
is that the typical >/dev/null was missed when it was
converted to use systemd-run.  The scriptlet before was:

    MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q

That is silent by design.  The MAN_NO_LOCALE_WARNING=1 was
added explicitly to avoid spurious output from the scriptlet
in 98f1386 ("suppress potential locale warning when
installing with glibc-minimal-langpack - resolves #1314633",
2016-03-14):

    https://src.fedoraproject.org/rpms/man-db/c/98f13860c7

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(When asked whether he liked children) "Ah yes...boiled or fried."
    -- W.C. Fields

Attachment: signature.asc
Description: PGP signature

_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Reply via email to