Its the āforceā being operative.
Something like
āMirror is weirdā > Syu > No sync refresh
āMirror is weirdā > -Syyu > Forced sync refresh
I guess Iāve been using āsyncā ā¦ when really thats the -S part ā¦ refresh, as for the package database.
That must be a feature that is very new (within the last few years) else it would not have left my system in a partial upgrade that needed to be fixed.
Its true that in the last few years there was some smarts added.
(hence the change of no longer suggesting ā-Syyuā even after pacman-mirrors, where previously it was a requirement)
Dont ask me for an exact date. I just know how it was vs how it is.
And thereās still room for more improvement.
No - they are not broken
I do think I am being misrepresented here - I donāt recall exemplifying anything like this.
Since I have been tagged - I have to say that I have had various observations over the years regarding pacman and how it handles sync.
Because I didnāt dive into the pacman code - I was heavily occupied in coding pacman-mirrors and at the same time learning the Python language - my understanding may have been flawed.
As you may recognise - this learning process may have led me to pass inaccurate understanding of the sync process onto my fellow community members - please accept my sincere apology for such inaccurate understanding.
With the HTTP protocol you can intercept the answer
When you use a single -y, pacman will compare the date of an existing metadata file and skip downloading if the dates are equal or newer.
How exactly the comparison is made will require a deep dive into the pacman and libalpm source code - I have not done so.
On the other hand, using a doubled -yy will instruct pacman to ignore Last-Modified and download anyway.
I have gathered some experience running a mirror and I know that file systems may be corrupted especially on SSD so I know from experience - this is possible.
Because mirrors sync at different intervals and because those syncs are done using rsync - mirrors may or may not use the --delay-updates option - there is a slight chance of short lived inconsistencies which may lead to 404 (Not Found) errors.
If a data corruption happens - the file may download but the content is garbage - thus the failure.
The only viable option for a member consuming that particular mirror will be to create a custom pool and exclude the mirror.
I provided an official for some years 2017-2021 if memory serves and that ran without hick-ups on my Synology diskstation.
When I a new workstation I repurposed the previous to run the mirror i5 quad core with 32G ram on 500Mbit fibre. The device was equipped with a PCI card with room for 4 mSATA SSD disks.
This was setup using and md/raid10 spanning four disk using EXT4 - and just like before the mirror synced every 5m with the mother repo.
BUT within a few months the file system became corrupted with no warnings the raid went offline. This happened several times over the next year - I eventually took down the mirror - it had become a burden - not a pleasure.
I still mirror Manjaro unofficially - this time on a RPI4B 8GB and 500GB m2 SSD.
This nothing new - it has always been so - if you sync correct you will never end in a partial sync.
You cannot create a partial sync using either -Syu or -Syyu.
The double -yy only force a sync of the metadata - and this is recommended when you switch mirrors using pacman-mirrors as you cannot predict if new primary mirrors metadata is newer or older than the current.
It has been argued that pacman is capable of updating the metadata thus the -Syyu has been changed to -Syu on the wiki and that change will only create 404 (Not Found) errors - never partial sync.
But as most is using pamac and pamac has a history of metadata inconsistencies - the use of the doubled -yyu has been necessary.
The only way you can create a partial upgrade is by using and up-to-date metadata to install one or more package(s).
Never do pacman -Sy <pkgname>
There is no way to characterize stack overflow filling 64GiB of RAM with garbage and slowing the system to near standstill due to then going into āpagingā mode, and thrashing my m.2 modules in the process ā which was what was happening ā as being ānot brokenā. And this was happening with both Pamac and Pacman, on my main home computer only. So, yes, something is ābrokenā to the extent that this behavior was possible. I suspect the bug is in the common library between Pamac and Pacman. Somewhere in the code, an infinite loop with unlimited memory leak is possible under some specific circumstance.
Personally, I donāt find this surprising. Not all edge cases can be tested, because itās impossible to imagine all possible scenarios. And Pamac / Pacman are not programs with billions of users. Maybe not even millions. How many people are using this software? 100,000? Something like that? The smaller the user base, the more āinterestingā behavior can slip through testing.
The exact trigger of the infinite loop remains unproven, though the ābad mirrorā hypothesis seems a good guess to me, especially seeing as how immediately after I refreshed mirrors to use ācurrently-up-to-date USA servers onlyā the problem want away, and seeing as how none of my other Manjaro computers (I use Manjaro both at home and at work) were experiencing this.
My takeaway from this is three things, really:
Keep an eye on my memory-usage meter when doing Pamac or Pacman updates and force-quit if it gets above 10GiB, because itās shown the ability to get into a loop and use unlimited memory (murder on m.2 SSD if it goes into paging).
Frequently update mirror lists.
Check pacdiff after all major updates and merge all pacnew files. (Iāve been practicing this. I think this will be easier if I change default diff-checker from āvi -dā to āmeldā, as Iām not a vi person.)
I just saw another topic Pamac Update Manager causes the system to freeze and while your initial topic suggests pacman is at fault - which is very unlikely - it appears similar with respect to the memory filling up.
It could be that your pamac update nag was causing the initial clogging.
I suggest to disable pamac update nag - and use only the native Arch Linux pacman.
%sudo pacman -S -yy -u --needed
Job start time: 01:26:34 PM
[sudo] password for aragorn:
:: Synchronizing package databasesā¦
core 144.7 KiB 348 KiB/s 00:00 [######################################] 100%
extra 8.6 MiB 33.3 MiB/s 00:00 [######################################] 100%
community 29.0 B 674 B/s 00:00 [######################################] 100%
multilib 143.5 KiB 2.98 MiB/s 00:00 [######################################] 100%
:: Starting full system upgradeā¦
error: could not read db āextraā (Damaged tar archive)
The dbās appears to be fetched correctly but when pacman is reading the files the content does not match what is expected - and is thrown away.
When pacman encounters an error it continues with the next mirror in the mirror list. When all mirrors has failed to provide the data - pacman errors out.
So either the filesystem on your local system produces an error which makes pacman discard the database or all mirrors provide the same error.
If all mirrors provide the same error - it is likely caused by your network connection - as it is next to impossible that all mirrors would have the same connection problem.
The native Arch Linux package manager pacman does not handle custom AUR scripts
If your system is seeing custom packages as updated after running
pacman -Syyu
Then you must have done something to rebuild your custom scripts prior to running pacman.
My issue started last night. Pamac was set to search for updates every 3 hours, this was the default setting from the last install - which I think was over a year ago but canāt say it has anything to do with any recent changes to calamares. And the swap file should be sufficient considering my memory is 16gb. When I realized it was the update part of pamac consuming my system memory and ultimately freezing the computer I turned off the auto update function. And restarted the computer - which now works normally.
However when initiating an update pamac again races to consume system memory - and thatās the bug I have. I have not let it run itās course as usually this results in the computer freezing so I just kill the process in task manager.
I have this problem as of tonight, Itās not Pacman its pamac background check that is consuming all memory and then starting to consuming all swap file as well causing my computer to be completely unresponsive and resulting in me having to press and hold my power button down to turn off my computer.
Rebooting and getting system monitor loaded before pamac could start itās background check is how i discovered that itās the background checker as i watched it just eat memory at an alarming rate, killing it stop it for a while but it soon run the checker again and started eating all my memory and swap.
For now i have loaded pamac gui and set it not to check for Updates and AUR Updates and turned off pamac gnome extension, so far it has not tried to background check, but i have not rebooted the computer yet.
If after a reboot it happens again i will have to uninstall all pamac files, unless someone knows what the hell is going on and why, and of cause how to fix this problem?
The developer is aware of the situation - as a fact - it was the developer, whom pinpointed the issue to be the AUR part of the GUI causing the issue.
There is no need to remove pamac - simply disable AUR for the GUI.
You will still be able to use command line pamac for searching AUR and building custom scripts.
So far after a few reboots/powered off with Pamac GUI check updates and AUR check updates turned off it has so far not happened again, Oh and Gnome Pamac updates indicator extension turned off.
I only used pamac to install a few AUR Programs (E.G. CKB-Next), all normal updates i do with Pacman and always have, and only used the Gnome Pamac updates indicator extension to let me know when updates are ready, then drop to TTY and update with pacman.
So i just have to run Pacman from terminal every day to check for updates, but will need to check AUR website manually to see if AUR Updates, unless i can somehow check and update AUR Programs without pamac?
Yes, use an AUR helper, such as: yay, trizen, paruā¦
A usual combination for me is
sudo pacman -Syu && paru -Sua
Though it may be worth noting that some of these helpers rely on their own history to check for updates.
So you may wish to feed all foreign packages to any new aur helper first; ex
Updates and AUR requisites:
sudo pacman -Syu git base-devel
Install, ex paru (manual AUR build):
git clone https://aur.archlinux.org/paru.git
cd paru
makepkg -sric
Feed all foreign packages to helper:
paru -S $(pacman -Qmq)
Now, for daily or common āregular updates then AUR updatesā see the first section of this post.
I have this exact problem. Pamac fills up all the RAM and SWAP and makes Gnome crash. The only way to avoid it is to kill the process.
I have tried to follow the advice you all give in this post but it doesnāt solve the problem for me. I still have to figure out how to stop pamac from running periodically, but my main problem is that I canāt use pacman normally either.
When I try to follow your advice I get the following errors, preventing me from installing paru.
...
error: target not found: libalpm.so>=14-64
==> ERROR: 'pacman' failed to install missing dependencies.
...
==> ERROR: Could not resolve all dependencies.
I have read other posts and they talked about mirrors, even the firewall. Well, my firewall doesnāt seem to be affecting (or so I think), while the mirrors have been reset and reassigned.
If this is the case, wouldnāt it be better not to use pamac and manage everything with pacman instead?
paru is an AUR package and you are apparently using the Stable branch, which is behind.
Great, I changed to unstable branch and it worked. Thank you!
I cannot tell you what is better and what not - this is your prerogative - your choice - your experience.
Personally I work largely without pamac - sometimes I want a gui search - but that has become rare.
The console and a virtual terminal is my primary lowlevel integration with the system.
I imagine many people (myself included) prefer that option.
Thereās a reason why many experienced users here do exactly thatā¦ but Iām not going to reopen that can of worms again, itās been discussed previously many times.
That was actually a genuine question because of my lack of experience. As I see a consensus in your comments I will do the same and use pacman instead. 
Back to the thread, I think itās important to mention that when I switched to unstable branch the RAM/SWAP consumption problem was solved. Now Iām back to the stable branch and everything is still fine.
I donāt know what could have caused that problem, but somehow changing mirrors solved it.