Restart loop in seafile-server and unknown server host db
#46
Comments
|
Hello, I could think of two reasons. Either, there some changes in the compose file that breaks the communication between the services or there are some issues in your underlying system regarding network functionality. If your database service is named Did you make any changes to the provided compose file other than the variables described in section "3. Set environment variables" of the documentation? |
|
Hi @ggogel, thank you for the response. In my compose file, I made the changes I described in #39, including my interpretations of the suggestions you made in your feedback. To be clear, my server does run; it works as intended when I run I still haven't restarted my server, so please let me know if you'd like me to try any debugging steps. I'm transcribing my compose file for reference, with emails and passwords edited out: version: '3.8'
services:
nginx-proxy:
container_name: nginx-proxy
image: nginxproxy/nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- certs:/etc/nginx/certs
- vhost:/etc/nginx/vhost.d
- html:/usr/share/nginx/html
- /var/run/docker.sock:/tmp/docker.sock:ro
networks:
- default
nginx-proxy-acme:
image: nginxproxy/acme-companion
volumes:
- certs:/etc/nginx/certs
- vhost:/etc/nginx/vhost.d
- html:/usr/share/nginx/html
- /var/run/docker.sock:/var/run/docker.sock:ro
- acme:/etc/acme.sh
environment:
- DEFAULT_EMAIL=someone@example.com
- NGINX_PROXY_CONTAINER=nginx-proxy
depends_on:
- nginx-proxy
networks:
- default
seafile-server:
image: ggogel/seafile-server:9.0.4
volumes:
- seafile-data:/shared
environment:
- DB_HOST=db
- DB_ROOT_PASSWD=foobar
- TIME_ZONE=America/Chicago
- HTTPS=true
- SEAFILE_SERVER_HOSTNAME=seafile.example.com # Mandatory on first deployment!
- GC_CRON=0 6 * * SUN # Garbage collection
depends_on:
- db
- memcached
- seafile-caddy
networks:
- seafile-net
seahub:
image: ggogel/seahub:9.0.4
volumes:
- seafile-data:/shared
- seahub-avatars:/shared/seafile/seahub-data/avatars
- seahub-custom:/shared/seafile/seahub-data/custom
environment:
- SEAFILE_ADMIN_EMAIL=someone@example.com
- SEAFILE_ADMIN_PASSWORD=foobaz
depends_on:
- seafile-server
- seafile-caddy
- seahub-media
networks:
- seafile-net
seahub-media:
image: ggogel/seahub-media:9.0.4
volumes:
- seahub-avatars:/usr/share/caddy/media/avatars
- seahub-custom:/usr/share/caddy/media/custom
depends_on:
- seafile-caddy
networks:
- seafile-net
db:
image: mariadb:10.7.1
environment:
- MYSQL_ROOT_PASSWORD=foobar
- MYSQL_LOG_CONSOLE=true
volumes:
- seafile-mariadb:/var/lib/mysql
networks:
- seafile-net
memcached:
image: memcached:1.6.14
entrypoint: memcached -m 1024
networks:
- seafile-net
seafile-caddy:
image: ggogel/seafile-caddy:1.0.6
networks:
- seafile-net
- default
environment:
- VIRTUAL_PORT=80
- VIRTUAL_HOST=seafile.example.com
- LETSENCRYPT_HOST=seafile.example.com
depends_on:
- nginx-proxy
- nginx-proxy-acme
networks:
seafile-net:
internal: true
volumes:
seafile-data:
seafile-mariadb:
seahub-avatars:
seahub-custom:
# https://github.com/nginx-proxy/acme-companion
certs:
vhost:
html:
acme: |
|
Ok, I misunderstood that. Well, from the logs it seems that both seafile and seahub are not able to resolve the hostname db anymore. So this could either mean that the db service isn't running anymore or there is an issue with the internal DNS of Docker. Did you check if the db service was running when this occured? Which version of Docker are you running and on what OS? |
|
I'm running Ubuntu 20.04.3 LTS on Digital Ocean. Here's the version output for It looks like the From what I'm reading, 137 suggests that either the container received a SIGKILL, or it might be running out of memory. I'm not sure why it might be receiving a SIGKILL, so I'm wondering if it's a memory issue. This is possible, since I'm running on the smallest instance on Digital Ocean. There's only 1 GB of memory. However, I've successfully run Seafile without Docker with no issues on this instance size for years. Maybe Docker is adding just enough overhead to where I'm running out of memory? Interestingly, If I run Here's the relevant snippet: The issue I'm encountering sounds like it may be similar to this one: Unfortunately, it was closed without a clear resolution... I'm at a bit of a loss as to how to debug this. I could increase the dropplet size so it has more RAM, but before I do that, I'd like to know for sure that I'm running out of memory, or at least have some clearer sense of what might be causing this issue. Do you have any tips on how I could find out what caused this container to crash? Thank you again for the help. Edit: It's probably worth noting that my server does not crash when undergoing high network load. I've had 3-5 people downloading multi-gigabyte libraries from it at the same time before, and it held up fine during that time. I wonder if there's maybe some sort of scheduled process that's causing it to crash. Does the timing of the crash suggest anything to you? |
|
I think it's very likely that the database service tries to allocate too much RAM. I dug out this article from MariaDB. It states that MariaDB uses at least 512MB of RAM by default. You can disable the Performance Schema to reduce this. Also, try to run |
|
@IllyaMoskvin Were you able to solve the issue? |
|
@ggogel Thanks for the follow-up. I think I was able to resolve the initial issue by doing the following:
For example: services:
db:
restart: always
image: mariadb:10.7.1
environment:
- MYSQL_ROOT_PASSWORD=<redacted>
- MYSQL_LOG_CONSOLE=true
volumes:
- seafile-mariadb:/var/lib/mysql
networks:
- seafile-netThat worked fine for almost two months, but recently, I started encountering new issues. I think they are unrelated to the initial issue in this thread. They might not be related to your package at all, but I might document them here for reference anyway. Maybe some other users of this package might find it useful. I'm currently working through the following issues:
Here's the current status: Restarting them naively doesn't work: I'll dig into these issues and either edit this comment or make a new one if I have success in solving them, but I just need to get something off my chest: I'm kind of disappointed in this whole "run Seafile through Docker" thing so far. I'd hoped that running it through Docker would ease installation and updates, but I've never run into this much trouble when I ran this stack directly on the DigitalOcean instance. I don't know what I'm doing wrong, but I feel like I keep getting burned here. I want to work through it, but I just hope the effort pays off in the long run. Please know that I don't think any of this is a fault of your package: I'm just a noob at Docker. But if anyone is passing through here from Google because you're having trouble getting Seafile working through Docker, just know that you're not alone! Edit: Closing because the initial issue is solved! |
I have no idea why you're running into so many issues. So you moved your Docker stack from the DigitalOcean Docker App to a VM? I hope that we can solve all the issues. |
|
Restarting the host (
I confirmed that if I stop the
Running If this issue happens again, I'll write a script for my crontab that runs
Not quite. For my initial Seafile installation, I installed it on a VM manually along with all of its dependencies. This would have been almost four years ago now. I decided that it was time to move it to a newer version of Ubuntu. This time, I wanted to install Seafile in a way that would make re-installing and upgrading it easier. My first instinct was to write Ansible recipes to automate the process of installing Seafile directly to the VM. However, I didn't find an existing "Seafile Ansible" project that looked trustworthy, and I wasn't quite ready to put in the effort to write my own from scratch. Your project looked great, however, so I decided to use this as an opportunity to try running it with Docker. This is my first time working with Docker. I can see that I have some things to learn about how to debug Docker containers! |
I'm running into some strange issues wherein my
seafile-serverseems to be stuck in a restart loop, and thedbservice appears to be unreachable. I'm also seeing some worrying "Could not bind socket" errors inseafile-server. In my client, I'm seeing "Library damaged on server" errors, but I think that's just inaccurate messaging.Then it loops, and I see the same sort of messages again.
Here are some from
seahub:Last logs from the
dbservice:I'm going to leave my server as-is for now in case you'd like me to supply any more info.
The text was updated successfully, but these errors were encountered: