At some point, I assume after an update in the last few weeks, the update-mime-database process has become agonizingly slow, taking 5 minutes or more to run. This is especially awful when running a system update that may call it multiple times.
For example, today I ran my usual “zypper ref;zypper up;zypper ps -s” routine that I run when I boot my computers (yes I update manually from the command line, I like to see what’s going on with updates). There were 142 updates today and update-mime-database was called by 7 of them. Each run took over 7 minutes! This made the updates take half an hour longer than they should have.
I identified the problem recently by noticing individual updates seemed to hang. Looking in my processes I found that update-mime-database was running each time. While top and atop showed that update-mime-database was using minimal CPU and memory resources, it still seemed to hold up the whole system each time it was run as part of another update’s update process.
Once I finished my updates, I rebooted, let the system settle and ran update-mime-database manually with the following results.
# time /usr/bin/update-mime-database /usr/share/mime
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
real 7m14.810s
user 0m0.736s
sys 0m20.704s
Seven minutes! Yikes.
Is this a problem for anyone else?
If so I’ll put in a problem report. If not, any tips on diagnosing and repairing the issue with the update-mime-database program?
Thanks for the replies guys!
The reference to the bugzilla report seems right on track. I’m going to try the test referenced by qantas94heavy as it’s referenced in the bugzilla report that deano_ferrari posted.
I’ll have to do this tomorrow when I get back on the laptop in question.
That post is interesting as it seems to have resolved the source of the issue without really fixing it globally. Instead relying on any package maintainers of packages that have the issue to fix it individually.
Fortunately in my case, I logged the zypper up output of the last update so I can identify all seven packages that have the issue. I’ll try and make reports for all of them and reference the original bugzilla report deano_ferrari listed in those reports.
FWIW to future Googlers finding this thread, my desktop which is also running OpenSUSE Leap 42.1 does not exhibit this behaviour. The main difference between these two is that the desktop was installed fresh with Leap 42.1 while the laptop with the issue was distro updated from 13.2. I’m wondering if distro update doesn’t properly replace some package scripts using the macros mentioned in the bugzilla report.
Anyway, I’ll update this thread with my findings and any resolution I come up with.
I can confirm that my laptop which was recently upgraded from 13.2 to Leap 42.2 is exhibiting the same behavior. I have Leap 42.1 running on my main laptop as a guest OS and that is not impacted.
# time /usr/bin/update-mime-database /usr/share/mime
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
real 1m3.722s
user 0m0.567s
sys 0m0.747s
There were several packages that called update-mime-database and no slowdown.
Then I ran the manual timed test
# time /usr/bin/update-mime-database /usr/share/mime
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
real 0m1.156s
user 0m0.608s
sys 0m0.412s
How’s that for an improvement?!
Gotta reboot after the updates…new kernel. Then I’m going to try force reinstalling the update mime package as was suggested and cross my fingers.
Well…too much to hope for I guess… here’s the output of the manual test after the forced shared-mime-info update.
# time /usr/bin/update-mime-database /usr/share/mime
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
real 4m31.483s
user 0m0.780s
sys 0m12.600s
So today I booted up my laptop, intending to open a bug report case on this issue. First, however, I ran my usual updates but forgot to make the export. After waiting a long time for the updates due to several of them running the update-mime-database call, I rebooted.
I got a notification that there were more updates. I ran those without the export as well and to my surprise there was no slow down even when update-mime-database was called twice.
The shared-mime-info package has been updated and the problem is fixed! Big thanks to fezhang@suse.com
Disable fdatasync() during installation time or when
PKGSYSTEM_ENABLE_FSYNC is set (bsc#862596) (fdo#70366)
Add shared-mime-info-disable-fdatasync-in-installation.patch
Sat 21 Nov 2015 05:00:00 AM MST fezhang@suse.com
Backport the fix from openSUSE:Factory to fix the slow
installation issue (bsc#862596)
The original openSUSE changelog comment by hrvoje.senjan@gmail.com:
Export ac_cv_func_fdatasync=no before calling configure, to
workaround the issue described in fdo#70366, where fdatasync()
is called on each update-mime-database invocation
So the problem is back. My guess is that some twit reverted the fix applied by fezhang@suse.com so we’re back to using the “export PKGSYSTEM_ENABLE_FSYNC=0” trick for now. Meanwhile I’ll see if I can find the culprit and give them a talking to.