Re: emba.gnu.org non-functional

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> Hi,

> emba.gnu.org does not cooperate any longer. The web access returns with
> "504 Gateway Time-out".
>
> The machine itself is accessible via ssh. Uptime looks normal.
>
> root@emba:~# uptime
>  12:48:15 up 8 days,  2:17,  1 user,  load average: 0.22, 0.17, 0.15
>
>
> Furthermore, it runs out of space:
>
> root@emba:~# df
> Filesystem                      1K-blocks      Used Available Use% Mounted on
> tmpfs                              812848     25388    787460   4% /run
> /dev/mapper/emba.gnu.org-crypt0 188691636 188691352       284 100% /
> tmpfs                             4064236        52   4064184   1% /dev/shm
> tmpfs                                5120         0      5120   0% /run/lock
> overlay                         188691636 188691352       284 100% 
> /var/lib/docker/overlay2/258b80131509190e6d09dfa7e11cb146c1d4ce74442c8db60ecb5f3d232c74ed/merged
> tmpfs                              812844         0    812844   0% /run/user/0
>
> Could somebody pls check what's up?

I've run the docker prune commands from crontab manually, and this gave
me some room on the disks. However, the used space is increasing, again,
and I have no idea why the entries in crontab are not sufficient in a
longer run.

Furthermore, we still have the problem that gitlab jobs fail due to
authentication timeout. One datapoint is that there are many ufw entries
in /var/log/messages for blocked connections. And you can see them added
in live by calling

--8<---------------cut here---------------start------------->8---
root@emba:~# tail -f /var/log/messages
--8<---------------cut here---------------end--------------->8---

and then, in parallel, accessing <https://emba.gnu.org/emacs/emacs/-/pipelines>.
Could it be, that the firewall has some undesired deny or limit rules
for the gitlab instance? Note, that I have closed to nothing knowledge
about firewalls.

Could we try an experiment, and disable the firewall for a short time,
and see whether gitlab is responding as expected then?

Best regards, Michael.