Pamac-cli and pamac-manager unreliable

[nikgnomic]

@denilsonsa

I’m curious to know why we should prefer one over another.

When pamac-gtk was updated to GTK4 for Manjaro Gnome in 2023 pamac-gtk3 was created for other desktop environments

@philm

With Pamac we have now 11.0.1 based on gtk4 and 10.5.3 based on gtk3

manjaro-gnome-23.0-230903-linux65.iso.pkgs:pamac-gtk 11.6.0-0.2

manjaro-kde-23.0-230903-linux65.iso.pkgs:pamac-gtk3 10.6.0-0.1

manjaro-xfce-23.0-230903-linux65.iso.pkgs:pamac-gtk3 10.6.0-0.1

@Aragorn

pamac-gtk3 is an older design than pamac-gtk. GTK4 is currently only used by GNOME and GNOME applications. If you’re on XFCE, Cinnamon, MATE, Budgie or even Plasma (which is not GTK-based), then you’re better off with pamac-gtk3.

@scotty65

Have you tried replacing pamac-gtk with pamac-gtk3 from the repos? I dumped pamac-gtk last year as it seems to be more suited to Gnome than Plasma due to its Adwaita dependencies. pamac-gtk3 works well on Plasma (at least it does on my mini-PC)

[varikonniemi]

Linux pretty much guarantees the original version of the library stays available until the program exits. The update must do something very exotic for pamac to know about some of it’s libraries being overwritten while the program is open, and this should not happen with a program like this.

I have seen one valid special case where it was understandable the running program crashed due to running an upgrade, and it was systemd due to a very special case for that specific update.

Generally, if an upgrade crashes a running program it’s a serious bug that should be fixed, not worked around by pushing everyone to use CLI. Of course you can use CLI to minimize the chance you experiencing such a corner case. But it should not be necessary on the stable branch, as the rare cases should have been caught and fixed during unstable and testing.

what i am saying is basically if you run stable, then you should be able to use GUI update, unless the release notes say that there is a know issue and CLI is recommended.

[Aragorn]

@varikonniemi

Linux pretty much guarantees the original version of the library stays available until the program exits. The update must do something very exotic for pamac to know about some of it’s libraries being overwritten while the program is open, and this should not happen with a program like this.

It doesn’t have to be exotic. All it takes is for an application to try and use a library that was not in use before and that was overwritten with a newer version, or for an application to make separate multi-threaded calls into the on-disk library, whereby one or several spawned-off threads are trying to access the library after it was already updated on disk.

@varikonniemi

I have seen one valid special case where it was understandable the running program crashed due to running an upgrade, and it was systemd due to a very special case for that specific update.

This sort of thing happens more frequently than one would think, though.

@varikonniemi

Generally, if an upgrade crashes a running program it’s a serious bug that should be fixed, not worked around by pushing everyone to use CLI.

It’s not necessarily a bug. It all depends on the design of the running program. Anything relying on threaded execution can be affected by this.

@varikonniemi

But it should not be necessary on the stable branch, as the rare cases should have been caught and fixed during unstable and testing.

Maybe, and maybe not. It is always possible for things to slip through unnoticed, or perhaps noticed but unreported.

@varikonniemi

what i am saying is basically if you run stable, then you should be able to use GUI update, unless the release notes say that there is a know issue and CLI is recommended.

In a perfect world, pamac would be free of bugs. But we do not live in a perfect world, and pamac has loads of open issues.

If you want a stable GUI front-end to the package manager, then use octopi. It uses pacman— the original and 99.99% bug-free package manager created by Arch Linux — in the background, along with an AUR helper.

pamac on the other hand was written from scratch, and even though it uses the ALPM database and package format, it does not use pacman itself. Instead, it was designed to handle repo packages, AUR packages, Snaps and FlatPaks all from within a single package manager, which makes it more into “a jack of all trades, but a master of none”.

[linux-aarhus]

@varikonniemi

Linux pretty much guarantees the original version of the library stays available until the program exits.

Does it?

My comment was a guess - not knowledge - a guess based on previous experience with other libraries, past experience with Windows libraries - a situation referred to dll-hell.

If the library is statically linked, there is no issue because the library will be attached to pamac binary itself.

But if it is dynamically linked, there is the risk of the library being replaced and therefore no longer available.

I have been in situations where I have updated my system - I usually look for a kernel update - that I know require restart - but if I forget - and that happens - I have had issues where I could not mount a file system.

After a restart - the file system mount as I expect; that kind of behaviour can only be attributed to expected libraries - dynamically linked - is no longer there - and that is why I suggested what you are referring to.

[denilsonsa]

And yet, I think this isn’t the cause of the crashes. As previously mentioned, the crash happened during an update that seemingly did not update lipalpm or any pacman/pamac-related package.

Also, it looks like it often (but not always) crashes during the download phase, before the backend even starts updating any package.

[linux-aarhus]

@denilsonsa

Also, it looks like it often (but not always) crashes during the download phase, before the backend even starts updating any package.

This may happen if your Pamac configuration has AUR enabled.

It has been seen that enabling AUR can cause a memory build-up in Pamac - which may lead to system crash or the process is killed by oom.

I find pamac convenient for certain tasks but for doing a full system sync - I prefer the command line and pacman.

[soundofthunder]

@denilsonsa

the crash happened during an update that seemingly did not update lipalpm or any pacman/pamac-related package.

Or, rather, the update didn’t complete due to the crash, and libalpm (and pacman and/or pamac related packages) failed as a result – a classic incomplete update scenario.

That is what you meant to suggest, is it not?

[linux-aarhus]

@linux-aarhus

I find pamac convenient for certain tasks but for doing a full system sync - I prefer the command line and pacman.

Don’t put too much into it, the opinions et.al. - my use of pacman is habit - I started my Arch journey with Arch and I went several Arch based distribution until a landed with Manjaro back in 2016.

I do use pamac as well - I have also used pamac gui to run complex updates and never had any issues, so you will never see me actively discourage the use of Pamac.

I did some research once on why pamac was eating memory which ultimately lead to crashes on low-spec systems; this was reported to the developer and then I left the topic.

But because there is so many issues with updates, and because one go tired in the explaining of the same over and over, then again, the recommendation on how to update was born.

The recommendation is based on logic; what happens when you update; a restart is required when kernel and gpu drivers are updated.

The preparation guide is also logic based; based on the fact that custom packages are unsupported; based on complaints that a system update can be huge, the recommendation is to clean the system for unused packages and orphans.

[denilsonsa]

@soundofthunder

Or, rather, the update didn’t complete due to the crash, and libalpm (and pacman and/or pamac related packages) failed as a result – a classic incomplete update scenario.

That is what you meant to suggest, is it not?

No, not that at all.

The last time it crashed for me, the list of packages to-be-updated/being-updated did NOT include any pacman/pamac-related package.

Additionally, pamac crashed, but the updated continued happening in the background. I could observe on my network monitor that packages were still being downloaded, and aterwards I could observe high CPU and I/O activity by monitoring in htop. After several minutes, the update was completed, which I could confirm by reopening pamac and seeing it shows zero remaining updates. (Well, maybe not zero, because it would show up pending AUR updates.)

And these are the main problems:

1. Pamac crashes. It shouldn’t. (But I understand this can be tricky to fix.)
2. It leaves the user with not feedback whatsoever that the update has continued in the background. I believe there should be at least some “safety net” fallback code that should trigger upon crashing, and that would provide bare-bones minimalistic feedback to the user until the update is finished.

Previous messages about the same issue:

• [Stable Update] 2025-02-04 - Kernels, KDE, XFCE, Mesa, Cosmic, Systemd - #56 by denilsonsa
• [Stable Update] 2025-02-04 - Kernels, KDE, XFCE, Mesa, Cosmic, Systemd - #65 by denilsonsa
• [Stable Update] 2025-02-04 - Kernels, KDE, XFCE, Mesa, Cosmic, Systemd - #124 by MarMJ
• [Stable Update] 2025-05-19 - Firefox, Thunderbird, KDE Gear, KDE Frameworks - #56 by denilsonsa
• [Stable Update] 2025-05-19 - Firefox, Thunderbird, KDE Gear, KDE Frameworks - #63 by denilsonsa

That’s why I have once suggested:

@denilsonsa

Suggestions:

1. pamac-manager should not crash.
2. In case it crashes, it should recover from it.
3. In case it crashes, it should probably/maybe abort the background update.
4. If the user re-launches the GUI after it has crashed, it should query background processes to figure out an update is already in progress and it should give feedback to the user.
5. If rebooting a machine during an update causes the system to become unbootable… Maybe the update should be more resilient and more atomic. It should survive an interruption. It is a common problem, and it shouldn’t be a problem.

@denilsonsa

There could be some crash handling code that would open a bare-bones window with tail -f pacman.log. That would at least give feedback to the user that work is still being done in the background.

---

@linux-aarhus

I did some research once on why pamac was eating memory which ultimately lead to crashes on low-spec systems

Definitely not my case. 32GB of RAM, and I constantly look at the RAM usage in a KDE Plasma panel. Plenty of memory available, nothing that even remotely looks like OOM at all.

[linux-aarhus]

@denilsonsa

I’m going to assume pamac is just a broken tool for system upgrades.

Don’t assume that - pamac is quite reliable - but as anything where humans are involved - it is not perfect.

@denilsonsa

pamac: error while loading shared libraries: libalpm.so.15: cannot open shared object file: No such file or directory

This happens very rarely - pacman/libalpm updates - so one cannot deduce that pamac is broken for system updates.

@denilsonsa

but the updated continued happening in the background

We can speculate and speculate and discuss the speculations

If I recall correct - I have been looking at Pamac’s vala codebase from time to time - the GUI is separate from the code that processes the packages.

When the GUI crashes but the process that handles the updates continues, it logically points to a situation where one or more libraries used by the GUI has been changed by the underlying process.

As I mentioned earlier - and as I am not the developer nor do I contribute to Pamac codebase so my comment on your question - should I create an issue about it still stands

@linux-aarhus

@denilsonsa

Should I create an issue about it

I don’t know how this can be handled, but making the developer aware that the update to pacman’s libalpm made pamac crash mid update - I agree.

The issue tracker is at GitHub - manjaro/pamac: Graphical Package Manager for Manjaro Linux with Alpm, AUR, Appstream, Flatpak and Snap support

When a package is upgraded the package manager

• removes the old version (trigger hooks related to uninstall)
• install the new version (trigger hooks related to upgrade)

So to cut it out - the package foo update is roughly equivalent to

sudo pacman -R foo
sudo pacman -S foo

[Aragorn]

@linux-aarhus

When the GUI crashes but the process that handles the updates continues, it logically points to a situation where one or more libraries used by the GUI has been changed by the underlying process.

One likely culprit would be gtk or gtk3, depending on which version of the pamac GUI is being used.

[nikgnomic]

@linux-aarhus

my comment on your question - should I create an issue about it still stands

Issue was reported last year:
Pamac GUI / CLI crashes during updates, but pamac-daemon does the job · Issue #523 · manjaro/pamac · GitHub
  [Stable Update] 2025-05-04 - #51 by Denis_Pom
  [Stable Update] 2025-07-12 - #48 by Denis_Pom

but stable branch updates for 2025-05-04 and 2025-07-12 do not include any pamac packages to suggest that updating via pamac should be problematic

Issue was reported for both versions of pamac GUI and pamac CLI, but only a small number of users were affected and not much information to help maintainers

Users reported pamac-daemon continues to update packages in the background, so pamac-daemon.service would probably not show any errors that would help

Pamac GUI users can check if the update was completed in View History or check /var/log/pacman.log. Pacman log does not include messages to advise if a .pacnew file has been created, so users should also use pacdiff -o to check

[varikonniemi]

All the libraries that have been loaded during program execution are safe and will not be updated for the runtime of the program. The previously mentioned case of newly loading a new library after version has been updated without the name reflecting it is the main issue case i guess.

But the main design of Linux memory management is that Linux tries to guarantee that in normal cases a running program will have the resources available to it for the duration of execution.

[nikgnomic]

For this problem, one KDE system has been reported to have had sufficient resources available to update stable branch packages, but pamac-cli was unable to provide feedback to confirm all packages were updated.

@denilsonsa

the crash happened during an update that seemingly did not update lipalpm or any pacman/pamac-related package.

libpamac, pamac-cli and pamac-gtk were last updated on stable branch 2025-12-22

Manjaro 2025-12-22 Stable Update

                         PACKAGE             20251215             20251222
---------------------------------------------------------------------------

                        libpamac             11.7.4-1             11.7.4-4
                  libpamac-debug             11.7.4-1             11.7.4-4
         libpamac-flatpak-plugin             11.7.4-1             11.7.4-4
            libpamac-snap-plugin             11.7.4-1             11.7.4-4

                       pamac-cli             11.7.4-1             11.7.4-2
                 pamac-cli-debug             11.7.4-1             11.7.4-2
                     pamac-debug             11.7.4-1             11.7.4-2
         pamac-gnome-integration             11.7.4-1             11.7.4-2
                       pamac-gtk             11.7.4-1             11.7.4-2

but pamac-gtk3 has not been updated since 2024

Manjaro 2024-11-30 - Stable Update

                         PACKAGE           2024-10-10           2024-11-30
---------------------------------------------------------------------------

                      pamac-gtk3             10.7.0-0             10.7.0-1
                pamac-gtk3-debug             10.7.0-0             10.7.0-1

[Teo]

I highly doubt there are human resources free to invest in maintaining 2 versions of the same thing for much longer, so i wisely switched to the gtk4 version, although i use xfce. There is no problem at all, except some theming issues which are fixable.

[tracyanne]

@linux-aarhus

Don’t assume that - pamac is quite reliable - but as anything where humans are involved - it is not perfect.

I know I whispered this earlier. But…

Personally I don’t get it.

Both of us use pamac-manager (the gtk3 edition on KDE Plasma) for all our updates. My partner on her 2 in 1, running Stable, myself on my laptop running Testing, and on the media machine running Stable.

Nether of us has any issues. Not when doing a full upgrade or when doing smaller updates on AURs and Flatpaks, or the firefox security updates.

Two of the machines in question have 8 Gig of RAM, while the Starlite has 16 Gig.

@linux-aarhus

If I recall correct - I have been looking at Pamac’s vala codebase from time to time - the GUI is separate from the code that processes the packages.

Where can I find the pamac code?

[varikonniemi]

and i am not even completely sure here if i attribute it wrongly, because it might be that it’s libc that does this, but it does not move the point

[Mirdarthos]

@tracyanne

Where can I find the pamac code?

Maybe here:

GitHub - manjaro/pamac: Graphical Package Manager for Manjaro Linux with...

[tracyanne]

@Mirdarthos

Maybe here:

Thanks.

[Aragorn]

@nikgnomic

pamac-gtk3 has not been updated since 2024

The Manjaro developer team has already long been planning to drop it in favor of the gtk4 version. To be honest, I’m surprised they haven’t done so yet.

Mind you, I personally don’t have a dog in that fight. I only use pamac-cli, and only so for AUR packages — I use pacman for anything from the repos.