[BUG] S6 overlay issue #23
Comments
|
I can't replicate this using your example compose on arm64, everything starts as I'd expect What is the output of |
|
|
Your docker install is (relatively) up to date so I wouldn't expect it to be causing any issues. Do you have another host you can try running the container on to see if you experience the same errors? |
|
Same docker-compose snipped works on a different machine (with x86 arch), so this is not a general bug in the image. |
|
The problem is it's not failing because it can't delete the folder, it's failing because it partially deletes it which then breaks the init process. If it was failing entirely it would start fine, the same as if it succeeded. You're not running rootless or anything like that are you? |
|
I am not running rootless or anything like that, just plain docker on Ubuntu Server. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Migrating my babybuddy to another box. I've had it running rootless with podman for a couple months. I think I'm seeing something similar: |
|
It appears this manifested with the tag: v1.13.2-ls62 To summarize above:
|
|
It's an issue we've previously only seen with LXC, the folder removal partially fails (even though it works if run interactively) and that causes the services to fail to start. |
|
Is it leveraging a pattern from the wider I typically deploy off |
|
The problem is it can't be fixed interactively (because the partially deleted service halts the init entirely). It might be possible for us to detect the failure pre-init but our only option in that situation would be to restore the deleted files because the delete doesn't work. It's not breaking to have the service present, it's just unnecessary, and I don't really want to put that logic in for such an edge case issue if I can avoid it. Because we're not able to replicate this in any of our test environments at the moment, it makes it hard to come up with any kind of "proper" solution for the issue. |
|
I guess I'm also a bit confused by the explanation, these files are all internal to the container image. It's not like permission for a mount/bind or selinux is the cause of the failure. Running interactively doesn't seem to result in a change: |
|
Ah, interesting. In the LXC cases we've seen before, it was possible to delete the folders interactively. |
|
@myxor do you remember what filesystems you were using for the working and nonworking instances you fiddled with? |
|
Hmm, can you provide the full output of |
Both using ext4 as filesystem. |
|
Yeah (below). I'd asked @myxor about filesystems because I realize that my original deployment was on I feel like the In this case the |
|
What we're doing with the babybuddy container is uncommon, though not unique, among our fleet so it's entirely possible you're not running anything else trying to perform the same actions. |
|
@thespad I joined the |
|
There's also this which is a very old bug but possibly a factor in some cases (not your zfs one though). |
|
If @myxor or others would want to follow the discussion can be found here. |
Is there an existing issue for this?
Current Behavior
When starting container it runs but i see the following log:
Expected Behavior
No response
Steps To Reproduce
Using this image:
when i start it the container is running but i see the log above
Environment
CPU architecture
arm64
Docker creation
babybuddy: image: lscr.io/linuxserver/babybuddy container_name: babybuddy environment: - PUID=1000 - PGID=1000 - TZ=Europe/Berlin - DB_ENGINE=django.db.backends.postgresql - DB_HOST=postgresql - DB_NAME=babybuddy - DB_PASSWORD=xxxx - DB_USER=babybuddy - DEBUG=1 - CSRF_TRUSTED_ORIGINS=http://192.168.200.2:8027,null volumes: - ~/babybuddy:/config ports: - 8000:8000 - 8027:8000 restart: unless-stoppedContainer logs
The text was updated successfully, but these errors were encountered: