Kategori CentOS

gitlab-runner docker unter redhat 7

Mittwoch, Mai 6th, 2020

Unter RedHat 7 wollte der neu installierte gitlab-runner nicht mit Docker reden:

ERROR: Job failed (system failure): Error response from daemon: oci runtime error: error running hook: exit status 127, stdout: , stderr: /usr/libexec/oci/hooks.d/oci-systemd-hook: error while loading shared libraries: libyajl.so.2: cannot open shared object file: No such file or directory (docker.go:882:0s)

Im Endeffekt war das Paket yajl nicht als Abhängigkeit verknüpft so das man es installieren muss:

yum install yajl

Docker CentOS6 php5.6

Montag, September 17th, 2018

Ein Dockerfile zum Bauen von PHP5.6 auf einem CentOS6 Image:

FROM centos:6
RUN yum -y groupinstall "Development Tools"
RUN yum -y --enablerepo=extras install epel-release
RUN yum install -y wget libxml2-devel libxml2 openssl-devel sqlite-devel bzip2-devel libcurl libcurl-devel libjpeg-turbo-devel openjpeg-libs openjpeg-devel libpng-devel libvpx-devel libxslt-devel net-snmp-devel readline-devel aspell-devel unixODBC-devel libicu-devel libc-client-devel freetype-devel libXpm-devel libpng-devel gmp gmp-devel libc-client libc-client-devel libmcrypt-devel libtidy libtidy-devel
RUN wget https://fossies.org/linux/misc/old/t1lib-5.1.2.tar.gz; tar -xzf t1lib-5.1.2.tar.gz; cd t1lib-5.1.2 && ./configure && make without_doc && make install
RUN git clone https://github.com/php/php-src.git
RUN cd php-src; git fetch origin PHP-5.6.38; git checkout -b php5.6 origin/PHP-5.6.38; echo 'LC_ALL="en_GB.utf8"' >> /etc/environment; export CXXFLAGS="-O3 -Os -s"; export CFLAGS="$CXXFLAGS"; ./buildconf --forcebuildconf --force && ./configure --disable-static --prefix=/opt/php-5.6 --with-config-file-path=/opt/php-5.6/etc --with-config-file-scan-dir=/opt/php-5.6/etc/conf.d --enable-bcmath=shared --enable-calendar --enable-exif=shared --enable-fpm --enable-intl=shared --enable-mbstring --enable-mysqlnd=shared --enable-ftp=shared --enable-opcache=shared --enable-pdo=shared --enable-shmop=shared --enable-soap=shared --enable-sockets=shared --enable-zip=shared --with-bz2=shared --with-curl=shared --with-freetype-dir=/usr --with-gettext=shared,/usr --with-gmp=shared --with-imap=shared --with-imap-ssl --with-jpeg-dir=/usr --with-kerberos --with-ldap-libs=/usr/lib/x86_64-linux-gnu --with-libxml-dir=/usr --with-mcrypt=shared,/usr --with-mhash=shared,/usr --with-mysql=shared,mysqlnd --with-mysqli=shared,mysqlnd --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-openssl --with-openssl-dir=/usr --with-pdo-mysql=shared,mysqlnd --with-pdo-sqlite=shared,/usr --with-png-dir=/usr --with-sqlite3=shared,/usr --with-t1lib=/usr --with-tidy=shared --with-xpm-dir=/usr --with-xsl=shared,/usr --with-zlib --with-zlib-dir=/usr --with-libdir=lib64 && make && make install

Kernel Bug in CentOS 7

Sonntag, Februar 12th, 2017

Nach dem neu starten unserer VServer Plattform mit dem Kernel 3.10.0-514, traten nach sofort nach dem Booten folgende schwerwiegenden Fehler im Log auf:

kernel: Buffer I/O error on dev dm-15, logical block 8892681, lost async page write
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 4:0:0:0: [sdc] Sense Key : Not Ready [current]
kernel: sd 4:0:0:0: [sdc] Add. Sense: Logical unit communication failure
kernel: sd 4:0:0:0: [sdc] CDB: Write(16) 8a 00 00 00 00 00 37 7d 48 00 00 00 40 00 00 00
kernel: blk_update_request: I/O error, dev sdc, sector 930957312
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aber auch folgende syslog events traten auf, nachdem mittels:

lvmcreate -L 10G -n lv_snapshot -S vg/lv

ein snapshot erzeugt wurde.

kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4718: Filesystem error recorded from previous mount: IO fail
ure
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4719: Marking fs in need of filesystem check.
kernel: EXT4-fs (dm-28): recovery complete
kernel: EXT4-fs (dm-28): mounted filesystem with ordered data mode. Opts: (null)
kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs (dm-28): orphan cleanup on readonly fs
kernel: EXT4-fs (dm-28): 6 orphan inodes deleted
kernel: EXT4-fs (dm-28): recovery complete

Schlimmer noch, die VMs wechselten nach kurzer Zeit in den read only Modus. Und konnten ohne erweitertes Filesystem Check nicht wieder gestart werden.

Zugglück sind wir schnell auf den Kernel Parameter gekommen, der das Problem verursacht hat.

cat /sys/block/sda/queue/max_sectors_kb
32767

Dieser Wert war bei älteren Servern noch auf 512 eingestellt. Bei den von dem Bug betroffenen Server durfte er nicht über 4096 eingestellt sein, stand aber immer wieder auf 8192.

Der CentOS Bug Report 12725, in dem das selbe verhalten mittels:

parted -s /dev/sda unit s print

beschrieben wurdet, half uns den Fehler weiter auf den Kernel einzuschränken. Immer wenn eine Partitionsabfrage, oder eine Änderung am LVM Stattgefunden hat, änderte sich der Wert plötzlich wieder auf 8192.

Folgende udev Regel, die wir unter /etc/udev/rules.d/99-san.rules eingefügt haben, verhinderte das umstellen des wertes:

ACTION=="add|change", ENV{ID_FS_USAGE}!="filesystem", ENV{ID_PATH}=="*-iscsi-*", RUN+="/bin/sh -c 'echo 4096 > /sys$DEVPATH/queue/max_sectors_kb'"

Fazit:
Ein so schwerwiegenden Kernel Bug ist mit schon lange nicht mehr untergekommen. Er hatte für uns zufolge das wir bei einzelnen VMs nur noch teile retten konnten und komplett aus dem Backup wiederhergestellt werden mussten. Auch das Rechercheiren des Bugs ist bei CentOS kaum möglich. Da es zu RedHat binär kompatibel kann man nicht einfach durch ein git repository zu scrolen und sich die Änderungen und Kommentare anschauen. Wo bei mir die Überlegung offen ist, zukünftig auf einen Vanilla-Kernel zu wechseln und/oder CentOS zu vermeiden.

Unser Kernel: 3.10.0-514.6.1.el7.x86_64
Quelle Burgreport: https://bugs.centos.org/view.php?id=12725

NTP Clients auf CentOS 7

Freitag, November 7th, 2014

Installation eines NTP Clients auf CentOS 7

Installation:
yum install ntp

Zeit von Hand updaten:
ntpdate de.pool.ntp.org

ggf. Zeitserver in der Config anpassen.
vim /etc/ntp.conf

Den ntp Dienst beim jetzt und beim Booten starten.
systemctl enable ntpd
systemctl start ntpd