March 2024 - Arch-general - lists.archlinux.org

[arch-general] System terribly slow
by riveravaldez 27 Oct '25

27 Oct '25

Hi, I'm looking for some advice trying to pinpoint why or where my system has becoming almost unusable slow. Searching the web I've found some hints but nothing precise enough. Maybe it's a failing HDD, but I'm first posting what I have until now in the hope someone can give some advice. Superficial symptoms are a general slowness. I'm using just IceWM and `startx` to initialize the GUI, and even logging into my account previous to that takes almost a minute to get done. Then any application I launch takes minutes to just start (from IceWM to firefox, from qtox to pcmanfm or geany, etc.). Even navigate the folders tree with pcmanfm takes 10 or more seconds just to show any folder content... Hope some of this helps: $ sudo journalctl -b -exp3 -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 19:50:29 -03. -- dic 03 00:48:43 arch kernel: sd 0:0:0:0: [sda] Asking for cache data failed dic 03 00:48:43 arch kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through dic 03 00:50:39 arch libvirtd[592]: cannot open directory '/home/dell/Software/VMs/TrisquelMini8': No existe el fichero o el directorio dic 03 00:50:39 arch libvirtd[592]: error interno: Falló al iniciar automáticamente el grupo de almacenamiento 'TrisquelMini8': cannot open directory '/home/dell/Softwar> dic 03 00:50:41 arch libvirtd[592]: No se encontró 'dmidecode' en ruta: No existe el fichero o el directorio dic 03 00:50:57 arch libvirtd[592]: No se encontró 'dmidecode' en ruta: No existe el fichero o el directorio dic 03 00:56:40 arch systemd[1]: Failed to start Disk Manager. Subject: A start job for unit udisks2.service has failed Defined-By: systemd Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel A start job for unit udisks2.service has finished with a failure. The job identifier is 1072 and the job result is failed. $ systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. $ systemd-analyze Startup finished in 11.038s (kernel) + 1min 31.352s (userspace) = 1min 42.391s graphical.target reached after 1min 31.352s in userspace $ systemd-analyze blame 37.946s polkit.service 29.248s dev-sda1.device 28.827s systemd-tmpfiles-clean.service 24.692s udisks2.service 15.936s systemd-journal-flush.service 14.228s systemd-hwdb-update.service 13.930s ldconfig.service 13.502s upower.service 12.881s ufw.service 8.830s user(a)1000.service 7.556s systemd-tmpfiles-setup-dev.service 7.280s avahi-daemon.service 7.275s bluetooth.service 7.262s iwd.service 6.067s systemd-logind.service 6.058s systemd-machined.service 5.825s systemd-tmpfiles-setup.service 5.123s systemd-sysusers.service 4.569s systemd-udevd.service 4.511s systemd-resolved.service 4.281s systemd-networkd.service 3.724s systemd-journal-catalog-update.service 3.415s systemd-fsck@dev-disk-by\x2duuid-1d72b82c\x2d9c58\x2d4f57\x2d97a3\x2de29ff35a5632.service 2.959s systemd-modules-load.service 2.557s lm_sensors.service 2.503s systemd-random-seed.service 2.389s systemd-backlight@backlight:acpi_video0.service 1.983s dev-disk-by\x2duuid-84c91978\x2da09c\x2d4087\x2db60d\x2d86730d142f63.swap 1.967s systemd-backlight@leds:dell::kbd_backlight.service 1.563s systemd-timesyncd.service 1.457s systemd-update-utmp.service 1.287s systemd-udev-trigger.service 1.278s systemd-rfkill.service 1.219s alsa-restore.service 1.164s systemd-sysctl.service (...) $ systemctl status polkit.service ● polkit.service - Authorization Manager Loaded: loaded (/usr/lib/systemd/system/polkit.service; static) Active: active (running) since Fri 2021-12-03 00:50:28 -03; 19h ago Docs: man:polkit(8) Main PID: 613 (polkitd) Tasks: 12 (limit: 6993) Memory: 18.9M CPU: 1.032s CGroup: /system.slice/polkit.service └─613 /usr/lib/polkit-1/polkitd --no-debug dic 03 00:49:50 arch systemd[1]: Starting Authorization Manager... dic 03 00:50:05 arch polkitd[613]: Started polkitd version 0.120 dic 03 00:50:26 arch polkitd[613]: Loading rules from directory /etc/polkit-1/rules.d dic 03 00:50:26 arch polkitd[613]: Loading rules from directory /usr/share/polkit-1/rules.d dic 03 00:50:28 arch polkitd[613]: Finished loading, compiling and executing 6 rules dic 03 00:50:28 arch systemd[1]: Started Authorization Manager. dic 03 00:50:28 arch polkitd[613]: Acquired the name org.freedesktop.PolicyKit1 on the system bus $ systemctl status dev-sda1.device ● dev-sda1.device - Hitachi_HTS545025B9A300 ROOT Follows: unit currently follows state of sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device Loaded: loaded Active: active (plugged) since Fri 2021-12-03 00:49:12 -03; 19h ago Device: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 Notice: journal has been rotated since unit was started, output may be incomplete. $ systemctl status systemd-tmpfiles-clean.service ○ systemd-tmpfiles-clean.service - Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static) Active: inactive (dead) since Fri 2021-12-03 01:03:52 -03; 19h ago TriggeredBy: ● systemd-tmpfiles-clean.timer Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Process: 1473 ExecStart=systemd-tmpfiles --clean (code=exited, status=0/SUCCESS) Main PID: 1473 (code=exited, status=0/SUCCESS) CPU: 185ms dic 03 01:03:23 arch systemd[1]: Starting Cleanup of Temporary Directories... dic 03 01:03:52 arch systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. dic 03 01:03:52 arch systemd[1]: Finished Cleanup of Temporary Directories. $ systemctl status udisks2.service ● udisks2.service - Disk Manager Loaded: loaded (/usr/lib/systemd/system/udisks2.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-12-03 00:59:51 -03; 19h ago Docs: man:udisks(8) Main PID: 1129 (udisksd) Tasks: 5 (limit: 6993) Memory: 3.2M CPU: 23.045s CGroup: /system.slice/udisks2.service └─1129 /usr/lib/udisks2/udisksd dic 03 00:59:26 arch systemd[1]: Starting Disk Manager... dic 03 00:59:26 arch udisksd[1129]: udisks daemon version 2.9.4 starting dic 03 00:59:51 arch systemd[1]: Started Disk Manager. dic 03 00:59:54 arch udisksd[1129]: Acquired the name org.freedesktop.UDisks2 on the system message bus $ systemctl status systemd-journal-flush.service ● systemd-journal-flush.service - Flush Journal to Persistent Storage Loaded: loaded (/usr/lib/systemd/system/systemd-journal-flush.service; static) Active: active (exited) since Fri 2021-12-03 00:48:59 -03; 19h ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Process: 283 ExecStart=journalctl --flush (code=exited, status=0/SUCCESS) Main PID: 283 (code=exited, status=0/SUCCESS) CPU: 15ms dic 03 00:48:43 arch systemd[1]: Starting Flush Journal to Persistent Storage... dic 03 00:48:59 arch systemd[1]: Finished Flush Journal to Persistent Storage. $ systemctl status systemd-hwdb-update.service ● systemd-hwdb-update.service - Rebuild Hardware Database Loaded: loaded (/usr/lib/systemd/system/systemd-hwdb-update.service; static) Active: active (exited) since Fri 2021-12-03 00:48:57 -03; 19h ago Docs: man:hwdb(7) man:systemd-hwdb(8) Process: 279 ExecStart=systemd-hwdb update (code=exited, status=0/SUCCESS) Main PID: 279 (code=exited, status=0/SUCCESS) CPU: 1.746s dic 03 00:48:57 arch systemd[1]: Finished Rebuild Hardware Database. $ journalctl -b -u systemd-journald.service -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 20:49:18 -03. -- dic 03 00:48:43 arch systemd-journald[271]: Journal started dic 03 00:48:43 arch systemd-journald[271]: Runtime Journal (/run/log/journal/431f639f382e4bad8a43628868f2fc6c) is 8.0M, max 292.4M, 284.4M free. dic 03 00:48:44 arch systemd-journald[271]: Time spent on flushing to /var/log/journal/431f639f382e4bad8a43628868f2fc6c is 7.561088s for 798 entries. dic 03 00:48:44 arch systemd-journald[271]: System Journal (/var/log/journal/431f639f382e4bad8a43628868f2fc6c) is 16.0M, max 2.4G, 2.4G free. $ journalctl -b -u systemd-fsck@dev-disk-by\\x2duuid-1d72b82c\\x2d9c58\\x2d4f57\\x2d97a3\\x2de29ff35a5632.service -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 20:52:36 -03. -- dic 03 00:49:18 arch systemd[1]: Starting File System Check on /dev/disk/by-uuid/1d72b82c-9c58-4f57-97a3-e29ff35a5632... dic 03 00:49:21 arch systemd-fsck[485]: HOME: limpio, 208781/13107200 ficheros, 37165716/52398592 bloques dic 03 00:49:21 arch systemd[1]: Finished File System Check on /dev/disk/by-uuid/1d72b82c-9c58-4f57-97a3-e29ff35a5632. $ journalctl --verify PASS: /var/log/journal/431f639f382e4bad8a43628868f2fc6c/user-1000.journal 3b84d8: Data object's entry array not sorted File corruption detected at /var/log/journal/431f639f382e4bad8a43628868f2fc6c/system.journal:915878 (of 16777216 bytes, 56%). FAIL: /var/log/journal/431f639f382e4bad8a43628868f2fc6c/system.journal (Mensaje erróneo) $ journalctl --disk-usage Archived and active journals take up 24.0M in the file system. Maybe it's pertinent to mention that I've just cleaned up /var/log/journal to rule out storage issues. Any help will be most welcome. Thanks a lot in advance.

6 8

the archlinux torrent
by Jude DaShiell 03 Jul '24

03 Jul '24

Having downloaded the torrent and burned the iso to a dvd I verified the torrent using sha256sum but apparently that wasn't enough since the installation broke part of the way through which means I ought to have used the gpg verification that is available online. What is done with those asc files to verify a download? I used lftp with no options on the command line and maybe that was also a mistake on my part. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

3 18

PAM 1.6 breaks limits.conf parsing
by Simone Baratta 12 Apr '24

12 Apr '24

Howdy, Arch community! Today Ardour warned me that I had a ulimit enforced for locked memory, and indeed I was surprised to find that `ulimit -l` reported 8192 for my user (which I configured to `unlimited` a long time ago). After a bit of investigation, it turned out that this is a bug introduced by PAM 1.6, which fails to read my limits.conf file due to the extra whitespace separating entries: ``` @audio - memlock unlimited ``` This makes pam_limits.so fail with the following: ``` pam_limits(login:session): wrong limit value ' unlimited' for limit type '-' ``` Looks like this issue was introduced with [1], and indeed I can confirm that it's fixed by [2] which references the first commit. Is there any chance we can get a 1.6.0-5 update with this patch in? This version is already in core, and it's a very subtle issue which is likely to be unnoticed by many but come with a lot of (possibly security-relevant) side effects. [1] https://github.com/linux-pam/linux-pam/commit/eec4358a49dc0d6d699532965f453… [2] https://github.com/linux-pam/linux-pam/commit/9228077d762fc94ebc8d9fb4edfe9… Thanks! -- Simone

2 2

Re: [arch-announce] The xz package has been backdoored
by Genes Lists 01 Apr '24

01 Apr '24

On Fri, 2024-03-29 at 18:55 +0000, Arch Linux: Recent news updates: David Runge wrote: > TL;DR: Upgrade your systems and container images **now**! > > Thanks for sharing. Truly an astounding revelation. This is a very, very sophisticated tool-chain attack along the lines of Ken Thompson's famous compiler trust example [1] Arch has been a strong advocate for reproducible builds [2] which can be part of a defense strategy [2]. I note that our xz package is marked as good in this regard [3]. I wonder what more we can reasonably do in the near term. Since git gives us decent tools to check what changed etc., I would imagine that can provide a stronger base on which to check things than working with tarballs or tarballs alone. This may have gone largely un-noticed for so long as people are probably more likely to check the source than the tarball itself. In this case, it seems, it was a primary developer doing the naughty - but they chose to leave the git repo alone and only infect the tarball. Question: -------- Would it make sense, therefore, to switch builds, where possible, away from tar files and instead pull directly from git source (signed tags where possible as usual etc)? Of course a git repo can also carry infections - perhaps taht's a little less likely. Or is this not worth the trouble? Gene [1] https://wiki.c2.com/?TheKenThompsonHack [2] https://reproducible-builds.org/ https://wiki.archlinux.org/title/DeveloperWiki:ReproducibleBuilds https://bootstrappable.org/ [3] https://reproducible.archlinux.org/ -- Gene

2 1

Which Emacs package?
by Abraham S.A.H. 31 Mar '24

31 Mar '24

Hey fellows; There are many Emacs packages available across Arch repositories and AUR. I list some of them here, in no specific order: From Extra repository: * emacs * emacs-wayland * emacs-nativecomp * emacs-nox From AUR and some third party repositories: * emacs-lucid-nativecomp * emacs-git * chaotic-aur/emacs-pgtk-native-comp-git I do not explain any of them for details. My audience is the one who already tried them, so can give me some advice. I already have tried all of them and also read archwiki's Emacs article. The Lucid one seems like the most stable with the least bugs, but with an archaic UI and without dnd support, but I do not use those scroll/menu/toolbars. Please, if you have any experience, share it with me. -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

5 6

man.archlinux.org/man/xzmore.1.uk is not in English
by u34＠net9.cf 30 Mar '24

30 Mar '24

https://man.archlinux.org/man/xzmore.1.uk manual page is not in English. Visually, I would say my local copy, man -l /usr/share/man/uk/man1/xzmore.1.gz , and xzmore.1.uk at man.archlinux.org have the same text. I also have many warnings, for a lot of packages, from pacman -Qkk. One of these warnings is about /usr/share/man/uk/man1/xzmore.1.gz. The warning is despite the fact the actaul data for /usr/share/man/uk/man1/xzmore.1.gz seems to agree with zgreping /var/lib/pacman/local/xz-5.6.1-2/mtree for that file. Local pacman version is 6.0.2-9. -- u34

3 4

Mensaje de ꪗꪮ𝘳ᦔꪖꪀ𝓽ꫀ
by ꪗꪮ𝘳ᦔꪖꪀ𝓽ꫀ 29 Mar '24

29 Mar '24

hello

1 0

Why after rebuild do I still get "warning: normalize: unknown key 'makepkgopt' in package description"?
by David C. Rankin 28 Mar '24

28 Mar '24

All, In whatever changed a week or so ago, pacman gave "... unknown key 'makepkgopt' in package description" for a slew of old packages left on my system from a decade of use. I've since gone back and removed all the packages and rebuilt the ones I need, but I still get a handful of errors for the 'normalize' package I've just built. What am I doing wrong? On cleaning the cache I get: 20:11 valkyrie:~> pms -c Packages to keep: All locally installed packages Cache directory: /var/cache/pacman/pkg/ :: Do you want to remove all other packages from cache? [Y/n] removing old packages from cache... warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description Database directory: /var/lib/pacman/ :: Do you want to remove unused repositories? [Y/n] removing unused sync repositories... The normalize package is the one I just built and updated from AUR, e.g 20:12 valkyrie:~> pmqi normalize Name : normalize Version : 0.7.7-7 Description : A tool for adjusting the volume of WAV files to a standard level Architecture : x86_64 URL : http://normalize.nongnu.org Licenses : GPL Groups : None Provides : None Depends On : audiofile libmad vorbis-tools lame flac mpg123 Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 118.49 KiB Packager : Unknown Packager Build Date : Tue 19 Mar 2024 08:07:32 PM CDT Install Date : Tue 19 Mar 2024 08:08:26 PM CDT Install Reason : Explicitly installed Install Script : No Validated By : None The PKGBUILD is: 20:13 valkyrie:~> cat arch/pkg/bld/normalize/PKGBUILD # $Id: PKGBUILD 266875 2017-11-15 14:29:11Z foutrelis $ # Maintainer: Giovanni Scafora <giovanni(a)archlinux.org> # Contributor: Tom Newsom <Jeepster(a)gmx.co.uk> pkgname=normalize pkgver=0.7.7 pkgrel=7 pkgdesc="A tool for adjusting the volume of WAV files to a standard level" arch=('x86_64') url="http://normalize.nongnu.org" license=('GPL') depends=('audiofile' 'libmad' 'vorbis-tools' 'lame' 'flac' 'mpg123') makedepends=('pkg-config' 'intltool') source=("http://download.savannah.gnu.org/releases/${pkgname}/${pkgname}-${pkgver}.t…" 'normalize-0.7.7-audiofile-pkgconfig.patch' 'normalize-0.7.7-m4.patch') md5sums=('1749b16fc7a08aa5d0cf9f76eeaa8436' '77d565e29bef11837e80347adfd42b58' '0b4bca7bf183275b9f939576ebad4233') prepare() { cd "${srcdir}/${pkgname}-${pkgver}" patch -Np1 -i "${srcdir}/normalize-0.7.7-audiofile-pkgconfig.patch" patch -Np0 -i "${srcdir}/normalize-0.7.7-m4.patch" touch AUTHORS NEWS ChangeLog #libtoolize --force --copy #aclocal -I m4 autoreconf -vi #automake --add-missing } build() { cd "${srcdir}/${pkgname}-${pkgver}" ./configure --prefix=/usr \ --mandir=/usr/share/man \ --with-audiofile \ --with-mad make } package() { cd "${srcdir}/${pkgname}-${pkgver}" make DESTDIR="${pkgdir}" install } Nowhere can I figure out where there is a "key 'makepkgopt' in package description". The package description is pkgdesc="A tool for adjusting the volume of WAV files to a standard level" Where is the "... key 'makepkgopt' ..." coming from? -- David C. Rankin, J.D.,P.E.

2 2

Re: Proposal to increase the default vm.max_map_count value
by Rein Fernhout (Levitating) 25 Mar '24

25 Mar '24

Seeing as other distributions have already adopted this change and gaming is a popular usecase for ArchLinux I do think this is a good thing to have. The default value will only be more of a bottleneck in the future. There's a balance in sticking to defaults. It'd be a shame if users need to alter multiple kernel parameters just to play modern games or run other applications with a high memory footprint. As I understand it there's no real downside to increasing this. Could someone with more knowledge of the kernel shed some light on any possible adverse effects that might come from increasing the default? I am also curious how the upstream discussed will go but I do not expect them to change it. Cheers, Levitating On 2024-03-25 09:10, Robin Candau wrote: > Hi everyone, > > I'm writing this mail as proposal to increase the default > `vm.max_map_count` [1] value in Arch Linux. > > The default `vm.max_map_count` 65530 value is making some Windows games > crash (or even prevent them to start at all) while being played through > Wine or Steam Play (Proton). > Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts > Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to > Valve for these games on that matter). > > In that regard, SteamOS is shipping an increased `vm.max_map_count` > default value to address the above issue and numerous distributions > have since then decided to implement that change on their side as well, > such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5]. > > While I'm aware that Arch is a user centric/DIY distro and everyone can > set their own `vm.max_map_count` value fairly easily, shipping an > increased value on our side would be a beneficial change to make in my > opinion as it would result in a smoother gaming experience out of the > box for our users without representing any downside/side effect (as far > as I'm aware). > > In terms of implementation, the change basically consists of shipping > the following sysctl file: > > ``` > # Increase the number of virtual memory areas that one process may > request > vm.max_map_count=1048576 > ``` > > For reference, Fedora added it to their systemd package [6], while > Ubuntu handled it at the procps level [7]. > I personally don't have a strong opinion on the implementation > way/place. > > To sum up, I think this would be a reasonable and positive change to > make to our distro. > I'd be happy to read your thoughts (or eventual objection)! 😊 > > [1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count > [2] > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 > [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount > [4] https://github.com/NixOS/nixpkgs/pull/238459 > [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 > [6] > https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf > [7] > https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4…

3 2

Do we need to fix dbus-broker-launch journal warnings -- or just ignore?
by David C. Rankin 25 Mar '24

25 Mar '24

Are we supposed to do anything to fix these dbus-broker-launch journal warnings? Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Service file '/usr/share/dbus-1/services/org.xfce.Tumbler.Thumbnailer1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Thumbnailer1'. Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Noticed file-system modification, trigger reload. Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Service file '/usr/share/dbus-1/services/org.xfce.Thunar.FileManager1.service' is not named after the D-Bus name 'org.freedesktop.FileManager1'. Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Service file '/usr/share/dbus-1/services/org.xfce.Tumbler.Cache1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Cache1'. I don't have XFCE installed, but do have thunar installed stand-alone for fluxbox. -- David C. Rankin, J.D.,P.E.

3 6