Re: What is this gibberish?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux