# Fallo al iniciar

**URL:** https://meta.discourse.org/t/failing-to-bootstrap/229024
**Category:** Self-hosting
**Created:** [4 Junio, 2022 18:46 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024 "2022-06-04T18:46:25Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![helmi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/helmi/32/114772_2.png) [@helmi](https://meta.discourse.org/u/helmi)
#### Post date: [4 Junio, 2022 18:46 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/1 "2022-06-04T18:46:25Z")

</div>

Esto está en una máquina de prueba. Anteriormente estaba ejecutando Discourse allí; estropeé la instalación y no pude actualizar a la última versión, lo que pensé que era mi error. Después de eliminar todo el directorio de Discourse y limpiar Docker, intenté hacer una instalación completamente nueva antes de importar una copia de seguridad de la base de datos en vivo.

Curiosamente, todavía estoy viendo los mismos problemas que no puedo resolver.

Aquí está la salida del error. Ya probé discourse-doctor, pero no arrojó nada útil.

```plaintext
...
I, [2022-06-04T18:42:29.087446 #1] INFO -- : Terminating async processes
I, [2022-06-04T18:42:29.087672 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 42
I, [2022-06-04T18:42:29.087881 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 103
2022-06-04 18:42:29.088 UTC [42] LOG: received fast shutdown request
103:signal-handler (1654368149) Received SIGTERM scheduling shutdown...
2022-06-04 18:42:29.118 UTC [42] LOG: aborting any active transactions
2022-06-04 18:42:29.123 UTC [42] LOG: background worker "logical replication launcher" (PID 51) exited with exit code 1
2022-06-04 18:42:29.123 UTC [46] LOG: shutting down
103:M 04 Jun 2022 18:42:29.154 # User requested shutdown...
103:M 04 Jun 2022 18:42:29.154 * Saving the final RDB snapshot before exiting.
103:M 04 Jun 2022 18:42:29.159 * DB saved on disk
103:M 04 Jun 2022 18:42:29.159 # Redis is now ready to exit, bye bye...
2022-06-04 18:42:29.201 UTC [42] LOG: database system is shut down

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse &amp;&amp; su discourse -c 'bundle exec rake db:migrate' failed with return #&lt;Process::Status: pid 1102 exit 1&gt;
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
**FAILED TO BOOTSTRAP** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
69cb25658efb6f16e4479bb98a2d0278d72e56028865730841ac1efacc5b8d9d
==================== END REBUILD LOG ====================

```

El servidor en sí debería estar bien: mucho espacio en disco, suficientes recursos en general. ¿Alguna idea?

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [4 Junio, 2022 19:55 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/2 "2022-06-04T19:55:02Z")

</div>

Necesitamos ver más del log, creo, y en particular ver qué pasó con ese comando rake.

Por favor, proporcione las salidas de

```plaintext
free
df

```

También podría ser relevante si su log incluye  
`WARNING overcommit_memory is set to 0!`

---

<div class="post-metadata">

### Author: ![helmi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/helmi/32/114772_2.png) [@helmi](https://meta.discourse.org/u/helmi)
#### Post date: [4 Junio, 2022 20:02 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/3 "2022-06-04T20:02:29Z")

</div>

> [@Ed\_S](#):
>
> También podría ser relevante si tu registro incluye  
> `WARNING overcommit_memory is set to 0!`

Lo hace:

```plaintext
103:M 04 Jun 2022 18:40:07.369 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

```

aquí está el resto que solicitaste:

```plaintext
root@testserver-2021:/var/discourse# free
              total used free shared buff/cache available
Mem: 16005396 353200 13366988 1100 2285208 15316292
Swap: 0 0 0
root@testserver-2021:/var/discourse# free -h
              total used free shared buff/cache available
Mem: 15Gi 343Mi 12Gi 1.0Mi 2.2Gi 14Gi
Swap: 0B 0B 0B
root@testserver-2021:/var/discourse# df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.7G 0 7.7G 0% /dev
tmpfs 1.6G 1.1M 1.6G 1% /run
/dev/sda1 226G 44G 173G 21% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup
/dev/sda15 61M 5.2M 55M 9% /boot/efi
overlay 226G 44G 173G 21% /var/lib/docker/overlay2/c9457cf1821fb558a92c79e55bd6a70153b8ae0388732aa5eef17237b6924c25/merged
overlay 226G 44G 173G 21% /var/lib/docker/overlay2/6d350b54871378d4b0e7ac5d30e236df3bdd1c45cd3b5fb2e9ab67ffe7a1bba1/merged
tmpfs 1.6G 0 1.6G 0% /run/user/0
overlay 226G 44G 173G 21% /var/lib/docker/overlay2/104be98cc5c33e73e4119d2186b6d9d08123ffc79df872f48425e94a66ca6749/merged

```

Supongo que los mensajes de overcommit se deben a que la memoria swap es 0. Curiosamente, eso nunca ha cambiado desde que existe este servidor.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [4 Junio, 2022 20:16 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/4 "2022-06-04T20:16:36Z")

</div>

Hmm… 16G de RAM es bastante, así que podrías pensar que no necesitas swap. Pero yo diría que no haría daño añadir un poco. Sin ver tu log no puedo decir que el problema sea la escasez de memoria. Pero si lo es, configurar el modo overcommit podría ayudar, tengas o no swap.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [5 Junio, 2022 07:38 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/6 "2022-06-05T07:38:17Z")

</div>

También podrías probar  
`dmesg | egrep -i "oom|memory"`  
para ver si algún proceso fue eliminado debido a una condición de falta de memoria.

Pero de nuevo, ver más de tu log probablemente ayudará.

Editar: ups, añadí el `-i`

---

<div class="post-metadata">

### Author: ![helmi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/helmi/32/114772_2.png) [@helmi](https://meta.discourse.org/u/helmi)
#### Post date: [5 Junio, 2022 12:16 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/7 "2022-06-05T12:16:15Z")

</div>

Creé un swap y también configuré el modo de sobreasignación. Desafortunadamente, nada cambió.

Aquí está todo el registro de la compilación de la aplicación [https://pastebin.com/raw/R2B8Wneu](https://pastebin.com/raw/R2B8Wneu)

Veo algunos fallos de redis que dicen que el puerto está en uso, pero no puedo ver de dónde viene esto

```plaintext
root@testserver-2021:~# sudo lsof -i -P -n | grep LISTEN
systemd 1 root 89u IPv6 15961 0t0 TCP *:9090 (LISTEN)
systemd-r 573 systemd-resolve 13u IPv4 10890 0t0 TCP 127.0.0.53:53 (LISTEN)
sshd 676 root 3u IPv4 20387 0t0 TCP *:22 (LISTEN)
sshd 676 root 4u IPv6 20389 0t0 TCP *:22 (LISTEN)
docker-pr 913 root 4u IPv4 23665 0t0 TCP *:9100 (LISTEN)
docker-pr 921 root 4u IPv6 21827 0t0 TCP *:9100 (LISTEN)
docker-pr 981 root 4u IPv4 24732 0t0 TCP *:3003 (LISTEN)
docker-pr 989 root 4u IPv6 22636 0t0 TCP *:3003 (LISTEN)
monitorix 1284 monitorix 3u IPv4 27978 0t0 TCP *:8080 (LISTEN)

```

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [5 Junio, 2022 14:57 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/8 "2022-06-05T14:57:14Z")

</div>

Gracias por el registro. Parece un problema de configuración de S3 (con el que no puedo ayudar, pero estoy seguro de que alguien podrá).

> I, [2022-06-05T09:06:10.144445 #1] INFO – : \> cd /var/www/discourse & su discourse -c ‘bundle exec rake db:migrate’  
> rake aborted!  
> Discourse::SiteSettingMissing: s3\_upload\_bucket  
> /var/www/discourse/lib/file\_store/s3\_store.rb:267:in `s3\_bucket’

---

<div class="post-metadata">

### Author: ![helmi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/helmi/32/114772_2.png) [@helmi](https://meta.discourse.org/u/helmi)
#### Post date: [5 Junio, 2022 16:28 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/9 "2022-06-05T16:28:47Z")

</div>

Buen hallazgo, Ed. Gracias. Parece que `s3_bucket` en algún momento cambió a `s3_upload_bucket` y tengo esos en `containers/app.yml`, lo que parece haber causado el problema. Al menos la compilación ahora fue bien después de que cambié `DISCOURSE_S3_BUCKET` allí a `DISCOURSE_S3_UPLOAD_BUCKET`.

Ojalá tales cambios también introdujeran una verificación en el proceso de compilación para evitar encontrarse con esto, y con suerte siempre probamos nuestras actualizaciones en una máquina de prueba.

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [5 Julio, 2022 16:29 UTC](https://meta.discourse.org/t/failing-to-bootstrap/229024/10 "2022-07-05T16:29:20Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
