RoR: Required ruby-2.4.2 is not installed

La síntesis:

– Se actualizo la version de ruby de la app a la 2.7.5
– En el archivo Gemfile se tiene:

ruby '2.7.5'

– En el archivo deploy.rb (capistrano) se tiene:

set :rvm_ruby_version, '2.7.5'

Pero al hacer el despliegue aun se tiene el siguiente mensaje de error:

Required ruby-2.4.2 is not installed

Para solucionar simplemente editar el archivo .ruby-version y cambiar el contenido por

2.7.5

Capistrano: Operation not permitted (Errno::EPERM)

Al ejecutar el deploy se tiene

/application.rb:383:in `kill': Operation not permitted (Errno::EPERM)
bundler: failed to load command: bin/delayed_job (bin/delayed_job)

Esto es debido a que se reinicio el servidor y quedaron algunos archivos pids residuales, basta con borrar estos archivos:

rm shared/tmp/pids/delayed_job.pid 

Y ejecutar de nuevo…

Centos: deshabilitar comando

Tuvimos un problema con el comando yarn, ya que había un bug y era inevitable que los usuarios sigan usando este comando, entonces la solución sería deshabilitarlo, para esto es necesario editar o crear el siguiente archivo:

/etc/profile.d/local.sh

Con el siguiente contenido

alias 'yarn=echo "command disabled..."'

Y listo eso es todo

MySQL: Acelerar la importación y exportación

Una alternativa (mas rápida) para el conocido mysqldump es mydumper, una herramienta simplemente esencial para la exportacion e importacion de bases de datos.

Tomar muy en cuenta que las versiones de mydumper y myloader tienen que ser las mismas.

El comando para exportar seria:

mydumper -u USER -p PASSWORD -h 127.0.0.1 -P 3306 -t 3 -c -l 3600 -s 10000000 -e --regex '^(?!(mysql|test|information_schema|performance_schema|sys))' -o backup/

Donde:

• -t 3, numero de hilos.
• -c, comprimir los archivos generados.
• -l 3600, el tiempo de espera antes de cortar la conexion.
• -s 10000000, socket de linux.
• -e –regex ‘^(?!(mysql|test|information_schema|performance_schema|sys))’, exportar todas las bases de datos, menos mysql, test, information_schema, performance_schema y sys.
• -o backup/, directorio donde se guardaran los archivos.

El comando para importar:

myloader -u USER -p PASSWORD --threads=8 -C -d backup/ -o

Donde:

• –threads=8, cantidad de hilos.
• -C, leer archivo comprimidos
• -d backup/, directorio de lectura
• -o, eliminar tablas si existen.

Es necesario agregar a la configuración de MySQL el siguiente parámetro:

max_allowed_packet=64M

CentOS 7: Read-only file system

Repentinamente todo el SO esta en modo escritura, una de las razones esta relacionado a procesos (Inodes) huérfanos. Cabe mencionar que no tenemos acceso directo al servidor, solo de manera remota.

Intentamos crear un archivo para verificar:

# touch test.txt
touch: cannot touch ‘test.txt’: Read-only file system

Revisamos los mensajes del diagnostico:

# dmesg
[83074.909312] systemd-journald[781]: Failed to write entry (21 items, 613 bytes), ignoring: Read-only file system

Intentamos reparar los errores con fsck

# fsck -f /dev/md4
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/md4 has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!

Procedemos a iniciar con una version de rescate, en este caso Debian y revisamos las particiones

rescue:~# fdisk -l
Disk /dev/ram0: 640 MiB, 671088640 bytes, 1310720 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 /dev/nvme0n1: 894.3 GiB, 960197124096 bytes, 1875385008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C836E485-806C-42EE-8078-4279D377AB7D

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 6143 4096 2M BIOS boot
/dev/nvme0n1p2 6144 3905535 3899392 1.9G Linux RAID
/dev/nvme0n1p3 3905536 11718655 7813120 3.7G Linux swap
/dev/nvme0n1p4 11718656 1875382271 1863663616 888.7G Linux RAID

Disk /dev/nvme1n1: 894.3 GiB, 960197124096 bytes, 1875385008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 61048823-5D74-4375-853B-7D0C6EF32E33

Device Start End Sectors Size Type
/dev/nvme1n1p1 2048 6143 4096 2M BIOS boot
/dev/nvme1n1p2 6144 3905535 3899392 1.9G Linux RAID
/dev/nvme1n1p3 3905536 11718655 7813120 3.7G Linux swap
/dev/nvme1n1p4 11718656 1875382271 1863663616 888.7G Linux RAID

Disk /dev/md127: 888.7 GiB, 954195574784 bytes, 1863663232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/md126: 1.9 GiB, 1996423168 bytes, 3899264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Seguidamente intentamos reparar las particiones fisicas:

• /dev/md126

rescue:~# fsck -f /dev/md126
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
boot: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
boot: 350/121920 files (14.0% non-contiguous), 52021/487408 blocks

• /dev/md127

rescue:~# fsck -f /dev/md127
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
root: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? yes
Inode 54264123 was part of the orphaned inode list. FIXED.
Inode 54264340 was part of the orphaned inode list. FIXED.
Inode 54264511 was part of the orphaned inode list. FIXED.
Inode 54265536 was part of the orphaned inode list. FIXED.
Deleted inode 54266256 has zero dtime. Fix? yes
root: FILE SYSTEM WAS MODIFIED
root: 968153/58245120 files (0.8% non-contiguous), 47404979/232957904 blocks

Finalmente procedemos a reiniciar el SO de manera normal.