AntiX 21 freezes randomly

[Moderator Brian Masinick]

Helpful

Up

0

::

Thanks @seaken64: ! I knew all of this is possible, but as I age, I’m forgetting more and more of the things that I once remembered by heart. GRUB_DEFAULT= is a handy option for those who want to frequently boot a specific kernel.

Excellent advice throughout your comments; thank you once again.

--
Brian Masinick

[Member stevesr0]

Helpful

Up

0

::

Hi seaken64,

Re: having to use “Boot Repair” after editing /etc/default/grub.

I thought the generic thing was to run “sudo update-grub”? Is boot repair an antix tool that runs that or does it do something different?

stevesr0

[Moderator caprea]

Helpful

Up

1

::

Hi stevesr0, yes you are right “sudo update-grub” is what you have to use after editing /etc/default/grub.

Hi seaken64, because antiX uses the “Advanced options” as a submenu on the boot screen,
it (the line with the submenu) needs to be selected first and then in which row the kernel you want to boot is presented (on the submenu) by using the > character

Don’t forget the lines start with 0 and then 1,2,..
and to update grub afterwards.

Example
GRUB_DEFAULT="1>2"

——————————————————

There’s another easy way to boot permanently into an older kernel.
Modify the /etc/default/grub like this by adding
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

Now the last selected kernel will boot continuous until you change it again by selecting another kernel on the bootmenu.
Update grub is required here too, of course.

[Member seaken64]

Helpful

Up

0

::

Ahh, yes, good point @caprea. I think there is also a variable to set the list to flat, instead of the advanced sub-menus. But using this tip from @caprea will not make that necessary.

You can use update-grub, or use the Boot Repair utility. Boot Repair calls the update-grub for you.

Seaken64

[Member wb8tyw]

Helpful

Up

0

::

Random freezing of a system with limited memory can be caused by the vm.swappiness setting.
For various definitions of what is “linited”.

By default anti-x 19 sets the vm.swappiness value to 10 in /etc/sysctl.conf.

It would be much better if anti-x put their custom values in something like /etc/sysctl.d/20-anti-x-settings.conf.

The lower the value of swappiness, the less Linux does a cleanup of moving memory into the swap file.

If you have plenty of memory, a low value may give you some faster response.

However the problem with a low value is that if you need to so any swapping at all, Linux does not have enough free memory available for the process that needs more memory, which is likely the program you most interested in at the moment, so it has to freeze that program while it goes around to all the other programs and swaps out some memory, repeating that process until it finally gets enough for the program you are using. This will show up as high CPU and high disk rate, if the monitoring programs are not victimized by this.

The default value of vm.swappiness for linux is documented to be 60.

On my laptop with a mere 4Gb, I had these freezes routinely until I commented out the value in /etc/sysctl.conf and added /etc/sysctl.d/95_local_swappiness.conf file with one line: vm.swappiness = 80.

Settings in the “xxx.d” directories is the preferred way to make customizations to packages that support them. This eliminates
the upgrade messages about someone has changed a file provided by this package.

With the higher swapiness, most of the hangs until a web browswer or visual studio code grow too big, are gone. I still have to restart those two applications every few days, because both apps will grow apparently until either the system crashes them or they hang/crash the system.

With a higher swappiness rate, most users will not see any issue, because most programs follow an “80/20 rule”. 80 % of programs use mostly 20% of the code / data.

So while your system is not busy, Linux starts copying parts of memory into the swapfile in the background, usually this is not noticed at all. Executable binaries (not scripts) are also effectively “readonly” swap files for this purpose.

The contents of the memory are not changed by this, and so if a program references the memory that was swapped out before it was reused, a soft page fault occurs and the memory is given back. Soft page faults are very fast because no disk I/O is involved.

But when a program needs memory, there is free memory to expand, and expanding to free memory is also a soft fault operation.

So what you need to know, to more precisely tune the swappiness value is how much memory is allocated for each memory expansion request by the kernel and multiply that by how many processes are CPU bound at one moment. I have not bothered to do that
calculation and just try addjusting swappiness upward until I still have a responsive system, and have minimized the hangs.

There is a formula to determine how much hard faults a system can tolerate with out impacting users, but you need to know some metrics and I do not remember all of them for Linux. Unfortunately for modern system that number is usually pretty low and
not worth calculating.

But back in the early days, knowing this calculation made a big difference on what you could actually get done with your systsem.

You need to know the number of processes that the CPU can run simultaneously with out visible load.
On a VAX/11-750, that number is 4.

You need to know the speed at which the CPU is reading instructions from memory. VAX/11-750 is .75 Mips.

You need to know the DMA transfer rate of the devices that the swap files are on. VAX/11-750 is 4 MB/second for the good disks.

As long as CPU speed in MIPS * number of active compute bound processes is less than the total MB/Second to for the swap file, users will pretty much not notice any swapping.

For most things that Linux is running on, the CPU / Memory speed makes it impossible for most swapfiles reads to be transparent, so there will be some impact to swapping.

Good luck.

[Member andyprough]

Helpful

Up

0

::

wb8tyw wrote:

With the higher swapiness, most of the hangs until a web browswer or visual studio code grow too big, are gone. I still have to restart those two applications every few days, because both apps will grow apparently until either the system crashes them or they hang/crash the system.

This is one thing I like about Pale Moon. Run it for several days without a restart, and it’s still sitting there using about the same amount of memory. Firefox and Chromium-based browsers go pretty insane with the memory usage over time. And it doesn’t take several days for it to be noticeable.

Thanks for the lengthy post otherwise. That’s some pretty interesting info you’ve accumulated.

[Member ModdIt]

Helpful

Up

0

::

Had forgotten these issues, In an older thread on this kind of issues there is also a recipe from xecure,
(really miss him). to move the cache to temp,
that only helps you if the machine gets shutdown pretty often.
rm ~/yourusername/.cache/mozilla/firefox
You can also issue the command in between times

for chromium or ungoogled chromium you may have to play a bit with the command
-rf $HOME/.cache/chromium

By the way only 4GB Ram is something many users of older machines would love to have.

[Author]

Posts