Samuel Sieb wrote:
> On 02/02/2018 04:31 AM, Tom Horsley wrote:
>> Just did a dnf update, this comes out:
>> 
>> ...
>>    Running scriptlet: firefox-58.0.1-1.fc27.x86_64                         
>> 18/18
>>    Running scriptlet: firefox-58.0-4.fc27.x86_64                           
>> 18/18
>> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
>> Running as unit: run-r329e01978cfe43258a05456898834edb.service
>>    Verifying        : GraphicsMagick-1.3.28-1.fc27.x86_64                   
>> 1/18
>>    Verifying        : GraphicsMagick-c++-1.3.28-1.fc27.x86_64               
>> 2/18
>> ...
>> 
>> Running as unit? Huh?
> 
> rpm is now running some tasks asynchronously using temporary systemd units.
> I don't know which tasks are being done this way, but I expect at least the
> mandb update is.  If you were quick enough, you should have been able to get
> more info by running "systemctl status
> run-r1880116b569f49288e6d0da0c5832367.service".

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.)

As you said, the man-db package includes a transaction
trigger which runs the man-db-cache-update service when any
package in the transaction adds or removes files from
/usr/share/man:

$ rpm -q --filetriggers man-db
transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/man
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
    /usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update || :
fi

# update cache
transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/man
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
    /usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update || :
fi

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.

Just knowing what it is is enough for me, I think.  It
worried me the first time I noticed it when updating a
package I built in a COPR, since I knew there were no
systemd scriptlets in that package.

I'm not sure why the man-db trigger scriptlets don't direct
output to /dev/null like most scriptlets.  It seems like
they should.  The systemd service call is logged, so if
there's a problem it should be visible in syslog.  Plus, the
output we get now is effectively worthless. :)

I submitted a patch to quiet this output:

    https://src.fedoraproject.org/rpms/man-db/pull-request/5

If that's accepted then we'll eventually stop seeing this
anytime an rpm installs or removes man pages.

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Man was made at the end of the week's work when God was tired.
    -- Mark Twain

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