Welcome to the May First Movement Technology Status Page

Please see below for any known interuptions to our service. If you are experiencing a problem not listed here, please open a support ticket.

Subscribe to an RSS feed of these alerts, get them by email, or learn how to subscribe to other messages.

Return to mayfirst.coop

julia is up, explanation of downtime

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Servers Affected/Servidores afectados: julia
Period Affected/Horas afectadas: 2019-04-09 3:15 - 9;45 am America/New_York
Date/Fecha: 2019-04-09

The server julia was down for approximately 6.5 hours early this morning
(America/New_York time). The initial hour of downtime was due to planned
maintenance as we upgraded the host server.

After upgrading the host server, julia failed to restart. Due to a lack of
helpful error messages, it took many hours before we identified the cause of
the problem. By 9:45 am America/New_York time the server was running again.

On every server, including virtual servers, there is a boot loader, an
intermediary program that is started when the server starts and has the task of
then booting the software that will ultimately run the server itself.

Most boot loaders output to a monitor by default. However, a virtual server has
no monitor, so instead we typically configure the boot loader to output to a
serial console (or a device that acts like a serial console that we can monitor
for errors).

On julia, the boot loader was not properly configured to output to the serial
console. In previous versions of our software, this mis-configuration was
simply ignored. The boot loader, even though it was not able to output to any
device, was still able to do its job and start the server. However, in the
current version of our software, this inability to output caused the boot
loader to crash with no helpful error messages.

Once we properly configured the boot loader on julia, we were able to
successful start the server.

We plan to avoid this problem in the future by changing our server maintenance
scripts to ensure this setting is properly configured on all servers.

In addition, our new infrastructure (in development) cleanly separates data
volumes from operating system volumes so that if a problem like this arises, it
will be trivial to rebuild the server from scratch and feed it the same data
volumes currently in use.

- --

El servidor julia estuvo inactivo aproximadamente 6,5 horas temprano esta
mañana.  (America / New_York time). La hora inicial de inactividad se debió a
lo previsto.  Mantenimiento a medida que actualizamos el servidor host.

Después de actualizar el servidor host, julia no pudo reiniciar. Debido a la
falta de mensajes de error útiles, pasaron muchas horas antes de que
identificáramos la causa de el problema. A las 9:45 am hora de América /
Nueva_trabajo el servidor se estaba ejecutando de nuevo.

En cada servidor, incluidos los servidores virtuales, hay un cargador de
arranque, un programa intermediario que se inicia cuando el servidor se inicia
y tiene la tarea de luego arranca el software que finalmente ejecutará el
servidor.

La mayoría de los cargadores de arranque dan salida a un monitor por defecto.
Sin embargo, un servidor virtual tiene no hay monitor, así que normalmente
configuramos el cargador de arranque para que salga a una consola serie (o un
dispositivo que actúa como una consola serie que podemos monitorear por
errores).

En julio, el cargador de arranque no estaba configurado correctamente para
enviar a la serie consola. En versiones anteriores de nuestro software, esta
configuración errónea era simplemente ignorado El cargador de arranque, a pesar
de que no fue capaz de salir a ningún dispositivo, todavía era capaz de hacer
su trabajo e iniciar el servidor. Sin embargo, en el versión actual de nuestro
software, esta incapacidad de salida causó el arranque El cargador se bloquea
sin mensajes de error útiles.

Una vez que configuramos correctamente el cargador de arranque en julia,
pudimos inicio exitoso del servidor.

Planeamos evitar este problema en el futuro al cambiar el mantenimiento de
nuestro servidor scripts para asegurar que esta configuración esté
correctamente configurada en todos los servidores.

Además, nuestra nueva infraestructura (en desarrollo) separa los datos
limpiamente volúmenes de los volúmenes del sistema operativo, de modo que si
surge un problema como este, será trivial reconstruir el servidor desde cero y
alimentarlo con los mismos datos Volúmenes actualmente en uso.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEH5wwyzz8XamYf6A1oBTAWmB7dTUFAlyss0UACgkQoBTAWmB7
dTVxkRAArf6n8RHTmX6vvaiqZADD+Z/VrC5zDuPp3vL4YMa7Bz96lmutK2HpyJ7k
T0qFcHCagDv6ev/avXUDWQ2W3tYmn29VozC6z9J91gWcjODIwynLWTtF8bopjiiu
baL2W01w2QLX3lzyYSdycWxYpmFy/76cteFnFKS2JM9/ZXECrnnYe+x+xFadjg8A
mBiZ0BiCi5+ak6Ou4Ecot7q1rY+ExJnCBgk7DrcciEsGsOTr36AUsFrjmD3l2X9l
zjJe7KLdS1zdlV0EJc2DWyg8afEEOevjQE8DcbFixnxuJpY8hO+l8Ycpn3EHusSU
bStC+8BBCdbV1SlGxjJUF8IZabbWLs4Tcss3j++pegqHPlx/NtuSGbrSbWiPXDNh
flmXTtc8jW7tVcP9hbj9bkqPxsHHbBwbN4vCJVdI1zncSozTysoz/YbW0nfgjcw+
N8N1/xHw1UI3r4YkRuPL7zjZsT9ZmdPee/9oS3KxdIRM6//iocCaGTQrUnR8ukJp
zK7WLY8CTyJf5QElcPd+e77bUMhRzUHQvpRJQb4KBdgc1lZM8WfcvcQCr6JuafjA
B4157XXEpTONL3B+JI7XnkQnNaPIdPg1USxKjPDkyCGHS4yG//r75snVKAMhB7AM
1gG5cvXMVKD8Jo7PmZEP4aTfzdFIdA1ofpM3MkuKjKemmdj7FJE=
=P8x8
-----END PGP SIGNATURE-----