You are not logged in.
Lately pacman is acting a bit strange here. Some packages takes several minutes to install, even if they are small packages. An example of such packages is kdebase-runtime.
If a run a normal pacman -S kdebase runtime the installation process hangs for 2-3 minutes at this point:
(1/1) reinstalling kdebase-runtime [############################################################] 100%
It happens every time I reinstall the package, and also when I upgrade it to a new version
If I run pacman -S --debug kdebase-runtime, I can see that it hangs at:
debug: executing "/usr/bin/bash" under chroot "/"
This happens when I run pacman via sudo, when I'm root and when I use a frontend like yaourt.
How can I debug this issue?
Edit: here are some benchmarks I did with the time command before pacman (time pacman -S <package name>). Of course I'm doing this with already downloaded packages, so that the download time is not taken into account.
kdepimlibs (affected):
real 1m31.312s
user 0m1.110s
sys 0m0.433s
calibre (affected):
real 1m33.768s
user 0m3.457s
sys 0m0.593s
vlc (not affected):
real 0m4.129s
user 0m1.893s
sys 0m0.210s
Last edited by Box0 (2013-11-09 11:51:12)
Offline
The problem isn't pacman, it's update-mime-database which is being called from the install scripts:
https://bugs.freedesktop.org/show_bug.cgi?id=70366
Offline
Thanks for the link.
It seems shared-mime-info devs are suggesting that this needs to be fixed at the package manager level. Anyway, until they decide what's the best way to fix this, would it be safe to downgrade to version 1.1?
Because this bug can be very annoying if you have to update lots of pakages (say ~100).
Last edited by Box0 (2013-11-09 13:01:25)
Offline
You might consider filing this against pacman. As a feature request. There are other reasons triggers would be useful. For example, right now the font cache is updated after each font package is installed, removed or upgraded. This can take a while if you install multiple font packages at once. The cache only really needs to be updated following the last transaction but I believe there is currently no way to implement that in Arch's packaging system. So the problem is a general one requiring a solution at the distro level even if this particular bug results in a configure option which could be used to avoid this particular delay.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
There has been a feature request for hooks since 2005.
Offline
There's https://aur.archlinux.org/packages/pacmannrd/ , maybe you cna create a similar workaround.
Offline
There has been a feature request for hooks since 2005.
I 'm not sure that's the same feature. Doesn't that provide a way to run a given whatever whenever a particular package is upgraded or installed? Whereas this would provide a sort of triggering facility so that multiple packages could request a trigger but it would get triggered only once. Or have I misunderstood the hooks request?
EDIT: Is there any reason you couldn't theoretically have a package which installed no files but merely ran an install script? If so, is there a way to force a package to be installed last? Because if so, couldn't you just put the trigger action in a package to be installed/upgraded/reinstalled as the final step?
Last edited by cfr (2013-11-17 03:10:04)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
apg wrote:There has been a feature request for hooks since 2005.
I 'm not sure that's the same feature. Doesn't that provide a way to run a given whatever whenever a particular package is upgraded or installed? Whereas this would provide a sort of triggering facility so that multiple packages could request a trigger but it would get triggered only once. Or have I misunderstood the hooks request?
The hooks are not intended to be package specific if that's what you're getting at. They would be triggered when certain packages/files were installed/upgraded/removed just like what you're talking about. See https://wiki.archlinux.org/index.php/Us … cman_Hooks
EDIT: Is there any reason you couldn't theoretically have a package which installed no files but merely ran an install script? If so, is there a way to force a package to be installed last? Because if so, couldn't you just put the trigger action in a package to be installed/upgraded/reinstalled as the final step?
The only way to force order would be to have the trigger package depend on every single package that needs the trigger.
Offline
But the idea of the triggers is that multiple packages would specify the same trigger yet pacman would only run the trigger once.
Yes, I thought order would be the problem.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Instead of running it once per package, it could run once per 'pacman -S foo bar baz' command, but pacman doesn't support transactions.
Offline
But the idea of the triggers is that multiple packages would specify the same trigger yet pacman would only run the trigger once.
If you look at the wiki page I linked, the current plan is for hooks to be able to specify whether they should be run per package or per transaction (as you would want for update-mime-database). in fact, the ability to run something once for the entire transaction is the main appeal of hooks.
Offline
I guess the problem was I had/have no idea what counts as a 'transaction' so that page really didn't tell me very much. Plus I read the bug as well which didn't make it sound like the same idea.
Anyway, it is all largely irrelevant since there's no sign anything like this will actually be implemented, is there?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
It is the same idea... Also, the generic ini-style config file parser need for this has been committed to pacman-git. So there is some progress.
Offline
Cool . Thank you for the update!
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I have problem 4 days in a row. I tried with mirror list change, last mirror list, tried also with various mirrors to put on top of list, from Germany, USA, Australia, France...none of them are working. When I try to do pacman -Syu , some of error that i got is:
error: failed retrieving file 'core.db' from mirror.de.leaseweb.net : Resolving timed out after 10519 milliseconds
error: failed to update core (download library error)
error: failed retrieving file 'extra.db' from mirror.de.leaseweb.net : Resolving timed out after 10519 milliseconds
error: failed to update extra (download library error)
This is my pacman.conf file:
#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives
#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir = /
#DBPath = /var/lib/pacman/
#CacheDir = /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
#GPGDir = /etc/pacman.d/gnupg/
HoldPkg = pacman glibc
#XferCommand = /usr/bin/curl -C - -f %u > %o
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta = 0.7
Architecture = auto
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg = audacity
#IgnoreGroup =
#NoUpgrade =
#NoExtract =
# Misc options
#UseSyslog
Color
#TotalDownload
CheckSpace
#VerbosePkgLists
# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required
# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.
#
# REPOSITORIES
# - can be defined here or included from another file
# - pacman will search repositories in the order defined here
# - local/custom mirrors can be added here or in separate files
# - repositories listed first will take precedence when packages
# have identical names, regardless of version number
# - URLs will have $repo replaced by the name of the current repo
# - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
# [repo-name]
# Server = ServerName
# Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#
# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.
#[testing]
#Include = /etc/pacman.d/mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
#[community-testing]
#Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.
#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist
#[archlinuxfr]
#SigLevel = PackageOptional
#Server= http://repo.archlinux.fr/$arch
#[archlinuxcn]
#The Chinese Arch Linux communities packages.
#SigLevel = PackageOptional
#Server = http://repo.archlinuxcn.org/$arch
#[herecura-stable]
# additional apps not found in community
#SigLevel = PackageOptional
#Server = http://repo.herecura.be/herecura-stable/$arch
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs
and last server that I`m using in mirror list file is Server = http://mirror.de.leaseweb.net/archlinux/$repo/os/$arch
I tried also with deleting all cache from pacman cache folder, with *.part file.
Last night was working fine, but this morning again, same issue.
Offline
I have problem 4 days in a row. I tried with mirror list change, last mirror list, tried also with various mirrors to put on top of list, from Germany, USA, Australia, France...none of them are working. When I try to do pacman -Syu , some of error that i got is:
Open a new thread, your post has nothing to do with the issue discussed here.
Offline
I have noticed this also and was wondering if my SSD performance was degrading because it used to zip right along, now it slows to a crawl at some points.
Offline
for the records, I just downgraded shared-mime-info to 1.1 and I plan to stick with it until a better solution shows up or something breaks in my box
Maybe it's because I do not update often (so when I do there are lots of packages to update) or maybe it's just me but I find this issue extremely annoying.
Offline
Glad to see this post
This bug makes me crazy
I found they have add an environment variable to disable fdatasync() in shared-mime-info.
# time PKGSYSTEM_DISABLE_FSYNC=1 ./update-mime-database /usr/share/mime
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
Unknown media type in type 'uri/mms'
Unknown media type in type 'uri/mmst'
Unknown media type in type 'uri/mmsu'
Unknown media type in type 'uri/pnm'
Unknown media type in type 'uri/rtspt'
Unknown media type in type 'uri/rtspu'
real 0m0.362s
user 0m0.294s
sys 0m0.068s
so we just need wait the new version of shared-mime-info and add this VAR
BTW, when will this package upgrade .....?
Last edited by vvilp (2013-12-07 07:27:23)
Offline
Umm... that has not made it to upstream git yet and has an objection to using environmental variables in the relevant bug report. So don't expect an update yet.
Offline
The gentoo people have provided a patch.
On my gentoo-system, the annoyance is gone with patch & v1.2.
http://sources.gentoo.org/cgi-bin/viewv … iew=markup
I'll patch arch's shared-mime-info-1.2 and report the result, since I am unsure if the patch is related.
My harddisk is under heavy stress with 1.2 on arch, contrary to gentoo. The hdd heads go crazy for minutes.
Last edited by artoo (2013-12-20 17:05:25)
Offline
The gentoo people have provided a patch.
On my gentoo-system, the annoyance is gone with patch & v1.2.http://sources.gentoo.org/cgi-bin/viewv … iew=markup
I'll patch arch's shared-mime-info-1.2 and report the result, since I am unsure if the patch is related.
My harddisk is under heavy stress with 1.2 on arch, contrary to gentoo. The hdd heads go crazy for minutes.
That patch is not related to this issue. Gentoo's is faster because they disable the fdatasync call at build time with
export ac_cv_func_fdatasync=no
as described in the bug report.
Offline
artoo wrote:The gentoo people have provided a patch.
On my gentoo-system, the annoyance is gone with patch & v1.2.http://sources.gentoo.org/cgi-bin/viewv … iew=markup
I'll patch arch's shared-mime-info-1.2 and report the result, since I am unsure if the patch is related.
My harddisk is under heavy stress with 1.2 on arch, contrary to gentoo. The hdd heads go crazy for minutes.
That patch is not related to this issue. Gentoo's is faster because they disable the fdatasync call at build time with
export ac_cv_func_fdatasync=no
as described in the bug report.
Yes, and me was thinking, it wouldn't build without glib patch.
Anyway, downgrade was the option of choice for the moment.
Offline
Yeah, annoyingly this is a security feature rather than a bug despite mimeinfo.cache easily fixable. Anyways, there's another option using libeatmydata
Rodrigo on AML tested it out:
Instead of a patch I've installed the libeatmydata package from the AUR and
added a file /usr/local/bin/update-mime-database that calls `exec eatmydata
update-mime-database "$@"`.Before: 21.618 s.
After: 0.275 s.A x100 improvement, that's something!
--
Rodrigo
Last edited by ssri (2014-01-18 09:11:59)
Offline