[centos 7.5] yum weigert te updaten

[AW_Bos]

Ik merk dat mijn server met CentOS 7.5 heeft geen zin meer heeft om updates via yum binnen te halen. Een reden ervoor kan ik niet vinden. Zelfs niet in de de melding die er met de oplossingen getoond wordt.

Hoe het is ontstaan? Geen idee, opeens gebeurde het....
Steeds krijg ik onderstaande melding bij het ophalen van updates, en stopt hij.

Ik heb een hoop geprobeerd:

1. /tmp leeggegooid
2. Server maar eens herstart (tja, eerste stap bij rare dingen )
3. yum clean all gedraaid
4. yum clean metadata gedraaid
5. De #'jes weggehaald voor de baseurl in /etc/yum.repos.d/CentOS-Base.repo

Ik kan proberen om de repo's te disablen, maar dat is ook niet echt de bedoeling. Ik wil gewoon dat hij alles binnenhaalt wat nodig is.

Ook snap ik niet waarom er op /var/cache/yum/x86_64/7/epel niks vrij is?
Alles draait prima, behalve dit?

Maar /dev/root wordt 100% gebruikt? Zou dat hiermee te maken hebben?

code:

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/root       20026236 19644860         0 100% /
devtmpfs         1012684        0   1012684   0% /dev
tmpfs            1013140        0   1013140   0% /dev/shm
tmpfs            1013140     9820   1003320   1% /run
tmpfs            1013140        0   1013140   0% /sys/fs/cgroup
/dev/sda2      459913320   739804 435788224   1% /home
tmpfs             202632        0    202632   0% /run/user/0

Ik zit even (weer) met mijn handen in het haar. Iemand die me op weg kan helpen?

code:

[root@myserver ~]# yum repolist all
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
epel/x86_64/metalink                                     |  26 kB     00:00
 * base: centos.mirrors.ovh.net
 * epel: epel.mirror.wearetriple.com
 * extras: centos.mirrors.ovh.net
 * updates: centos.mirrors.ovh.net


 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Insufficient space in download directory /var/cache/yum/x86_64/7/epel
    * free   0
    * needed 100 k

De output is van /etc/yum.repos.d/CentOS-Base.repo is als volgt:

code:

[root@myserver ~]# cat /etc/yum.repos.d/CentOS-Base.repo
# CentOS-Base.repo
#
# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client.  You should use this for CentOS updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the
# remarked out baseurl= line instead.
#
#

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

[Bart]

Insufficient space in download directory /var/cache/yum/x86_64/7/epel

Aan je 'df' output te zien valt deze directory onder de / mount en daar is, zoals je zelf al hebt gezien, geen ruimte meer.

[AW_Bos]

Hm, mijn bevindingen zijn dus juist....

Hm.. hoe zou dat kunnen? /tmp is geleegd
De services draaien verder prima.

Ik heb dit nog nooit eerder meegemaakt....

[ Voor 15% gewijzigd door AW_Bos op 05-04-2019 22:10 ]

[Thralas]

AW_Bos schreef op vrijdag 5 april 2019 @ 22:09:
Hm.. hoe zou dat kunnen? /tmp is geleegd

Die vraag kan alleen jij beantwoorden.

Maak wat ruimte, en installeer daarna ncdu, ideaal om je disk mee op te ruimen.

De services draaien verder prima.

Dat is meer geluk dan wijsheid. Enorm veel dingen zullen vroeg-of-laat op onvoorspelbare wijze stoppen met werken. 100% use van je rootfs dien je zsm. te verhelpen en maatregelen te nemen om het te voorkomen in het vervolg.

[Cyphax]

AW_Bos schreef op vrijdag 5 april 2019 @ 22:09:
Hm, mijn bevindingen zijn dus juist....

Hm.. hoe zou dat kunnen? /tmp is geleegd
De services draaien verder prima.

Ik heb dit nog nooit eerder meegemaakt....

Wellicht in /var ergens, daar zou ik beginnen. En /home. Luister naar de wijze raad van @Thralas en gebruik ncdu, die maakt je leven in dit soort gevallen veel makkelijk.

[AW_Bos]

Even een greep uit dit, wat de grootste bestanden uit / toont...
find / -type f -size +10000k -exec ls -lh {} \; | awk '{print $5 ": " $9}' | sort -nr | head -n 40

code:

240M: /usr/sbin/mysqld
188M: /var/lib/mysql/iff/footnote.ibd
161M: /usr/sbin/mysqld-debug
132M: /var/lib/mysql/iff/timetable_validity.ibd
124M: /var/lib/mysql/iff/timetable_service.ibd
102M: /usr/lib/locale/locale-archive
92M: /var/lib/mysql/iff/timetable_transport.ibd
90M: /home/aar/serviceinfo/cache/iff_parsed/changes.tsv
75M: /var/lib/rpm/Packages
60M: /var/lib/mysql/iff/timetable_platform.ibd
56M: /var/lib/mysql/iff/timetable_stop.ibd
54M: /var/log/btmp-20190401
48M: /var/lib/mysql/ib_logfile1
48M: /var/lib/mysql/ib_logfile0
47M: /usr/lib64/mysql/mecab/dic/ipadic_utf-8/sys.dic
37M: /usr/lib64/mysql/mecab/dic/ipadic_euc-jp/sys.dic

Dit is peanuts vergeleken met een schijf van 200 GB

[Hero of Time]

Je kan oudere kernels weggooien. Standaard worden er 3 bewaard. Als je al de laatste draait, kan je de andere twee opruimen.

Ga daarna na wat er zoveel gebruikt. Je hebt zo te zien 20 GB? Dat zou voldoende moeten zijn, maar dat is afhankelijk van wat je met de server doet. Je hebt daarnaast een /home van 450 GB. En daar gebruik je praktisch niets van. Beetje onevenredig gebruik van schijfruimte, vind je niet?

Is het een VPS of machine thuis? Afhankelijk van het filesystem dat er voor /home is gebruikt, kan je wat schuiven met de ruimte. Al vraag ik mij al wel af wat /dev/root voor apparaat is.

[AW_Bos]

Het is een dedicated server van OVH.
Ik snap het ook niet, zo is de server voor mij opgeleverd.

En ja, ik wil graag ncdu gebruiken, maar dat werkt dus niet op deze manier
Als / vol lijkt te zijn dan lijkt het mij beter om die wat op te rekken. Heb ik dat correct? En wat is de best practice?

[ Voor 54% gewijzigd door AW_Bos op 05-04-2019 22:22 ]

[Hero of Time]

Maar du heb je wel, en daar kan je al veel uit halen. Begin maar eens met dit:

du -sh /*

En werk je weg door de grotere mappen. Meestal dus /var.

[AW_Bos]

Hebbes, een uit de kluiten gegroeide MySQL database met data die ik toch niet (meer) gebruik.
Database heb ik maar hardhandig verwijderd. Ik had ook niet verwacht dat die database zo groot zou worden.

Nu maar eens kijken hoe ik de ruimte veilig kan verbeteren, want deze partionering lijkt toch problemen op te leveren.

[ Voor 12% gewijzigd door AW_Bos op 05-04-2019 22:37 ]

[Hero of Time]

Kijk in /etc/fstab of via het mount commando welk filesystem er gebruikt wordt voor / en /home. Laat ook even de uitvoer van fdisk -l zien, om te weten wat /dev/root nou precies is vergeleken met /dev/sda2.

[AW_Bos]

code:

[root@myserver var]# mount
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1012684k,nr_inodes=253171,mode=755)
sysfs on /sys type sysfs (rw,relatime)
proc on /proc type proc (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/sda2 on /home type ext4 (rw,relatime,data=ordered)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=202632k,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)

code:

[root@myserver var]# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1       /       ext4    errors=remount-ro       0       1
/dev/sda2       /home   ext4    defaults        1       2
/dev/sda3       swap    swap    defaults        0       0
proc            /proc   proc    defaults                0       0
sysfs           /sys    sysfs   defaults                0       0
tmpfs           /dev/shm        tmpfs   defaults        0       0
devpts          /dev/pts        devpts  defaults        0       0

code:

[root@myserver var]# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x000c32fd

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        4096    40962047    20478976   83  Linux
/dev/sda2        40962048   975718399   467378176   83  Linux
/dev/sda3       975718400   976764927      523264   82  Linux swap / Solaris

De conclusie die ik zover kan trekken, is dat /home als type ext4 op /dev/sda2 staat.
En root als ext4 op /dev/sda1.

Met enig schaamrood op de kaken moet ik zeggen dat ik dit nog nooit vaak zo heb gezien, omdat ik meestal met VPS'en werk waarbij er een centrale simfs-filesystem wordt gebruikt voor zowel / als /home.
In dit geval van een dedicated server is daar natuurlijk geen sprake van.

Is het wijsheid om die 20 GB voor die /dev/sda1 op te rekken, mocht ik in de toekomst wel met grote databases werken? Voor die /home wordt toch inderdaad onevenredig veel gereserveerd

[ninjazx9r98]

Je kunt er ook voor kiezen om de locatie van je databases uit het root filesystem te halen en daar een aparte partitie voor te maken. Is ook een betere oplossing imho, als die vol loopt is je root filesystem nog niet vol en dat geeft je letterlijk en figuurlijk meer ruimte om het probleem op te lossen.
Een keuze zou kunnen zijn om root zo klein mogelijk te houden en alles wat potentieel veel en snel zou kunnen groeien onderbrengen in een eigen partitie/filesystem.

[AW_Bos]

Op sich is dat geen slecht idee. Database zijn ook overigens geen programma's...
Nu kijken hoe ik dit netjes kan doen. Als iemand nog tips heeft...

Of zou /home een goede plek zijn? Wel vreemd dat dat niet standaard gebeurt?
Zou dat een reden hebben?

[ Voor 28% gewijzigd door AW_Bos op 05-04-2019 23:43 ]

[Hero of Time]

Zo te zien een swap van 512 MB, / van 20 GB en /home van ~450 GB. Je kan met parted makkelijk wat ruimte van je /home afhalen. Let wel, je kan die ruimte niet zomaar 'eventjes' aan / toekennen, want verkleinen wordt meestal aan het eind van een partitie gedaan en /home staat direct achter /. Het is daarom verstandiger om de vrije ruimte voor bijvoorbeeld /var of /var/mysql te gebruiken.

Je zit ook nog eens met 3 partities nu, op een DOS (oftewel MBR) partitie indeling. Je weet wat daar de beperkingen van zijn neem ik aan en wat daarmee dus ook gelijk je opties zijn.

Ik weet niet of je direct met root in kan loggen op die machine, maar ik zou de schijfindeling iets anders aanpakken en naast / een LVM volume maken zodat je /home en swap daarin kan zetten, samen met /var (of /var/mysql) en alle andere benodigdheden. Dankzij LVM ben je ook nog eens extra flexibel en kan je makkelijker volumes veranderen van grootte.

Oh, u vroeg om tips. Nou, hier dus een paar.

Edit:
Het is an sich mogelijk om /home te gebruiken voor je database, maar dat vereist wat configuratie aan mysql. Iets dat bij onoplettendheid overschreven kan worden. Beter de locatie zelf naar een schijf ombouwen.

[ Voor 10% gewijzigd door Hero of Time op 05-04-2019 23:44 ]

[AW_Bos]

Mooie tips!
Ik ga me er eens in verdiepen