Pamac Update Manager causes the system to freeze

Were you in the midst of updating/rebuilding AUR packages when this happened?

And I have seen it for an experienced user as well - Bizarre Pamac & Pacman behavior: used 62GiB memory, took 10min to refresh DBs - I thought is was a single instance - I stand corrected.

I suggest to disable pamac update nag - and use only the native Arch Linux pacman.

Pamac consist of several packages and several utilities depend on pamac.

If you do not use those utilities there is no reason to keep them.

  • manjaro-application-utility - both a standalone and a plugin to manjaro-hello
  • python-manjaro-sdk - provides integration between manjaro specific applications
  • web-installer-url-handler - provides a mimetype to be handled by pamac

That is definitely a problem - wonder if an issue has been created at gitlab?

I just took a look at gitlab and there is a topic RAM usage of pamac-manager above 700-800 MB just to open it (#1381) · Issues · Applications / pamac · GitLab on the initial memory consumption.

The user’s system had 20 updates - occupying 7-800MB RAM - one can imagine what a stable update with 100’s of packages changed can do.

Taking some deep diving into this and data from my own system - it may be reasonable to look at the LordTermor / Pamac tray icon for plasma · GitLab tray.

1 Like

I would also raise the swapfile.

For 16 GB RAM, I would also go with 16 GB Swap.

I have a ‘swapfile’ function to go, where you could add to your rc file, monitoring with a program like htop how it’s go’s and adjust the size if needed.

Swapfile
# swapfile
swap-activate() {

    echo "How much MB should your swapfile have?"
    echo "Enter here: "
    read -r i

    while ! [[ "$i" =~ ^[0-9]+$ ]]; do
        echo "memory size, has to be numbers"
        echo "try again: "
        read -r i
    done

    echo -e 'Do you want to use \e[38;2;242;29;0m'"${i}"'\e[0mMB?'
    echo "Press y are Enter to continue"

    read -r r

    if [[ "$r" =~ ^[Yy]$ ]] || [[ "$r" == "" ]]; then

        sudo swapoff /swapfile &&
            sh -c "sudo rm /swapfile" &&
            sudo dd if=/dev/zero of=/swapfile bs=1M count="$i" status=progress &&
            sh -c "sudo chmod 600 /swapfile" &&
            sudo mkswap /swapfile &&
            sudo swapon /swapfile &&
            cat <<'EOF' >/etc/sysctl.d/99-swappiness.conf

    vm.swappiness=6
    vm.vfs_cache_pressure=66
    vm.dirty_ratio=3
    # sudo sysctl vm.vfs_cache_pressure=100
    # sudo sysctl vm.swappiness=8
    # sudo mkinitcpio -P
EOF
        if sh -c "sudo grep -q '/swapfile' /etc/fstab"; then
            echo "Entry already exists in /etc/fstab"
        else
            #todo    sudo echo "/swapfile none swap defaults 0 0" >>/etc/fstab
            #    echo "Entry added to /etc/fstab"

            echo "need to add to fstab"
        fi
    else
        echo "swapfile cancelled.."
    fi
}
1 Like

no I was not - but the issue is related to the auto update function in pamac.

Having disabled autoupdate in pamac - how does this impact the update of AUR & Flatpack packages?

I had to do a manual update to check for any updates and keep getting a pop up that says it has failed to synchronize the AUR databases.

Although 2 applications were updated mkincpio & msedge with no apparent issues.

Regarding the individual with a similar problem with runaway memory should I understand this to mean that it took 10 mins to refresh (internal)databases - filled 62gb of memory with spurious data in the process before the machine froze or started working normally again? I don’t quite understand the situation as I never saw any odd data just my memory being consumed rapidly which ultimately led to the freezing state of my computer. I did let it run for about 10 mins and noticed every now and then that I did regain very limited control of the mouse, but that was all, they keyboard lights would eventually go out and a hard reset was the only way back.

I’ll do some tests later unless of course there’s a fix.
(not sure if I want to use a different update tool as this might cause complications/confusions in the future - but will keep on eye on github and here in the meantime)

Thank you all for your assistance.

We are all guilty of promoting a paradigm where you must keep your system up-to-date several times a day.

That is waste of time an bandwidth - at least for me - my system functions without any issues even though I run unstable branch and updates when I remember it or when I sync a package I need.

I have come to point with my system - I prefer it in running state and only update when I sync a new package.

I have another system which I check with first and thus the system is only updated when I need to check - verify an issue so to speak

disable AUR update check
disable the flatpak update check

Search for the phrase check-aur.sh for a non-intrusive check for changed AUR scripts.

With flatpak you can run a simple command in a terminal.

The similarity I saw was your statement

which looked very much the same with regards to filling available system memory and pamac.

I realised, when I revisited the topic, they were not quite the same.

EDIT
@Nicomo
After some testing by watching process with htop and doing some pamac related tasks - I discovered there was some pids which - depending on the tasks - would come and go.

I provided some data to the pamac developer and was asked if the same pids were active if I disabled AUR in pamac.

And thereby we discovered that disabling AUR removed all excess pids for the pamac-tray-plasma and the pamac-daemon.

I am quite sure the developer is catching up the issue.

Until then - disabling AUR in Pamac will ensure no excess memory usage and dangling pids.

3 Likes

Some AUR packages do require a lot of space, at least on disk. Waterfox is (or at least was) one offender; I had to mount an external drive to compile it on as only had a 25G / at the time.

I can’t remember how much RAM it gobbled up, though. :man_shrugging:

This is wise and similar to what I do; check everything is OK (usually for a day or so) before rolling out the updates to the other systems, particularly my mate’s T430.

1 Like

I just got the same problem right now. Start PC, log in, pamac-checkupdate take so much ram it crash the whole system. I have to say that I personnaly like pamac. I found the gui to search is better for me than the command line. And the update notification is good to have (at least for me). I disable the notification to at least be able to start without the problem in the future. But I found the solution of just uninstalling to be not the best.

I started pamac manually, and go the update section. Same problems happens.
I then did the update manually in command line (with pacman). It upgraded 2 packages:
Packages (2) chromium-121.0.6167.85-1 firefox-122.0-1
I then started pamac again in the update section and the bug is not there anymore! YES!
Will try to use it a bit again in the coming days to see if the problem come back.

The issue seems to have resolved itself or perhaps a number of recent updates addressed and resolved the issue. I have returned to my original auto update settings and have not seen any issues over the last two days. Updates seem to be passing through without a hitch. I turned on updates for AUR after and they worked fine too.

I’ll update or create a new post if anything goes wrong further in the week that might be related. Thanks to all of you who offered and provided advice

Same exact issue now
With a system that has 32GB of RAM I get always to 28 to 29GB of RAM used by pamac-checkupdates and the result is an UNUSABLE PC
It becomes NOT responsive until I get to the System Activity and kill that process

How can it be ??

Never had an issue with pamac so far

I have the latest version (just today updates few more apps)
Any help ?

Clear your build cache.

Build cache is clean
I removed the check for updates since NO solution works so far

Same thing happens when I use pacman from command prompt

Excuse me, what now?
Did you really mean to say pacman (Arch’s package manager also usable on Manjaro) or rather pamac (Manjaro package manager, which this thread is all about).

The problem is originated in pamac (Manjaro GUI for the package manager) and I found that before deciding to to stop the auto “check for updates” also when I was using pacman commands (Arch’s pakcage manager) the process named pamac-checkupdates was triggered.

That is the reason why I added the comment since when I stopped with the updates in pamac all became normal, except I will manually check if any updates came out.

Hope it is clear now :slight_smile:

The problem still lies within pamac - one just can trigger it’s execution by using pacman.

Correct.
But is there any other solution other than turning off the “check updates” ??

Did you bother to read [comment #17]?

There has been no updates to pamac-{gtk,gtk3} since the last build in mid December 2023 and libpamac since December 2. 2023 - so one can only specualte what changes the OP has made prior to posting that comment.

So if you are having these memory issues the current recipe is disable AUR.

1 Like

A simple no would have been enough and yes I did “bother” to read that is why I asked

If it helps:
Turn off auto updates, including flatpak & AUR.
Restart your box.
Run pamac and manually check for updates and if there are no updates then clear the cache on exit.
Restart your machine and turn on autoupdates. (I think I turned on flatpak & AUR after things worked first)

The problem does not persist in my desktop. That’s what seems to have happened to me.
I will mark this as my solution.

I am going to test it this evening

It is WORKING