Skip to content


strace -ftttTvyyo /tmp/rpm-strace.out -s 4096 

Memory Usage

ps -e -o pid,vsz,comm= | sort -n -k 2 | tail -n 5
ps aux | head -1; ps aux | sort -rnk 4 | head -5
ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n

Linux Version Checking

cat /etc/*release


yum install redhat-lsb-core

DNF / YUM Repo Mirroring, Syncing, Creation

Mirroring, Syncing, and Creating repos

sudo yum install yum-utils createrepo

sudo dnf install dnf-utils createrepo

To do the initial sync

mkdir -p /mnt/your/repo/mirror/here
reposync --repoid=REPOID --arch=x86_64 --plugins --download_path=/mnt/your/repo/mirror/here

This will sync whatever repoid (eg epel) you specify, only the x86_64 packages, will allow it to use the yum/dnf plugins, and sync it to your mirror dir. Omitting the repoid flag will sync ALL the repos on the system (/etc/yum.repos.d/)

Once the mirror is created you can sync it, verify it, and delete the old packages

reposync --repoid=REPOID -arch=x86_64 --plugins --gpgcheck --delete --download_path=/mnt/your/repo/mirror/here

If you need to do a quick sync you can add --newest-only and it will just sync the newest packages. Adding the --download-metadata flag might be needed for some repos. For example if you want to directly use the repo without running createrepo on it.

If you have a collection of RPMs that need to be put together in a repo, update a repo after running reposync, or fix a local mirror with bad metadata, use the createrepo command.

createrepo /mnt/your/repo/mirror/here

If you have a large repo you will want to setup a cache. This will improve your entire repo creation speed at the cost of some disk space.

mkdir -p /mnt/your/repo/mirror/here/.repocache
createrepo --update --deltas --cachedir /mnt/your/repo/mirror/here/.repocache /mnt/your/repo/mirror/here

If you're having problems you can use the --workers flag to set the number workers. By default it will use as many workers as you have threads. Another way of speeding up the process is to remove the --deltas flag to prevent it from generating deltas. It may also be prudent to set nice & ionice levels depending on your system. For non-ssd storage, and/or SAN storage, I typically recommend limiting workers to no more than half of the available threads, nice level of 15, and ionice class of 3. This will make sure the system has plenty of resources to handle large repos without impacting other services. For SSD backed storage, especially local SSDs, ionice typically is not needed unless your storage throughput is limited by something like LUKS.


Harding the boxes