search

linuxserver / docker-calibre

GNU General Public License v3.0
338 stars 62 forks source link

Newer than 6.4 won't work on Unraid 6.11.0 #106

Closed wizzy99 closed 1 year ago

wizzy99 commented 1 year ago

linuxserver.io

Expected Behavior

Calibre starts, GUI is available.

Current Behavior

Calibre doesn't appear to start. Connecting to GUI results in "ERR_CONNECTION_REFUSED"

Steps to Reproduce

  1. Install linuxserver/calibre:latest (anything newer than linuxserver/calibre:6.4.0)
  2. Set extra parameters to "--security-opt seccomp=unconfined" (same result without this param)
  3. Start docker image
  4. Try to connect

Environment

OS: Unraid CPU architecture: x86_64 How docker service was installed: Unraid download from linuxserver/calibre:latest Docker version: Docker version 20.10.17, build 100c701

Command used to create docker container (run/create/compose/screenshot)

Calibre Docker config

Docker logs

[migrations] started [migrations] no migrations found usermod: no changes

      _         ()
     | |  ___   _    __
     | | / __| | |  /  \
     | | \__ \ | | | () |
     |_| |___/ |_|  \__/

Brought to you by linuxserver.io

To support LSIO projects visit: https://www.linuxserver.io/donate/

GID/UID

User uid: 99 User gid: 100

No auth enabled. To enable auth, you can set the PASSWORD var in docker arguments. [custom-init] No custom files found, skipping...

Comparison of "ps" for 6.6 (not working / top) and 6.4 (working/bottom)

calibre combined - 6 6 top 6 4 bottom

github-actions[bot] commented 1 year ago

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

saltydk commented 1 year ago

Log from testing this particular issue on a regular Ubuntu 22.04 install.

s6-rc: info: service init-keygen successfully started
s6-rc: info: service init-rdesktop: starting
s6-rc: info: service init-rdesktop successfully started
s6-rc: info: service init-video: starting
s6-rc: info: service init-video successfully started
s6-rc: info: service init-rdesktop-end: starting
s6-rc: info: service init-rdesktop-end successfully started
s6-rc: info: service init-autostart-config: starting
s6-rc: info: service init-autostart-config successfully started
s6-rc: info: service init-rdesktop-web-end: starting
s6-rc: info: service init-config: starting
s6-rc: info: service init-rdesktop-web-end successfully started
s6-rc: info: service init-calibre-config: starting
s6-rc: info: service init-config successfully started
**** Setting password from environment variable. ****
s6-rc: info: service init-calibre-config successfully started
s6-rc: info: service init-config-end: starting
s6-rc: info: service init-config-end successfully started
s6-rc: info: service init-mods: starting
s6-rc: info: service init-mods successfully started
s6-rc: info: service init-mods-package-install: starting
s6-rc: info: service init-mods-package-install successfully started
s6-rc: info: service init-mods-end: starting
s6-rc: info: service init-mods-end successfully started
s6-rc: info: service init-custom-files: starting
[custom-init] No custom files found, skipping...
s6-rc: info: service init-custom-files successfully started
s6-rc: info: service init-services: starting
s6-rc: info: service init-services successfully started
s6-rc: info: service svc-xrdp-sesman: starting

Nothing happens after that.

drizuid commented 1 year ago

UPDATE: sorry i just realized you already have this present. ignore me.

due to seccomp issue with unraid, fix is to add the security_opt listed below. https://docs.linuxserver.io/faq#rdesktop

cbachmann987 commented 1 year ago

I am not 100% sure if it is the same cause: I have a podman setup running that works fine until 6.4 - when updating to anything newer starting from 6.5, the same "ERR_CONNECTION_REFUSED" as described above happens.

--security-opt seccomp=unconfined does not change anything on this.

The logs of the container look like this:

image

drizuid commented 1 year ago

we think this is getting hung up due to ipv6 and @saltydk has actually submitted 2 PRs that SHOULD fix it, though we need a PR for alpine too. https://github.com/linuxserver/docker-baseimage-rdesktop/pull/21

i've just merged these and we are waiting on builds

djbobyd commented 1 year ago

Hello, I am also facing this issue and I can confirm that it is happening on podman and containerd but everything is working fine in the docker environment. What I was able to see from the changelog of the calibre container is that it stopped working after s6 version 3 was introduced. The images before 6.5 were using the old s6 and are working fine in podman/containerd. I don't know if it's related but worth mentioning. Let's hope the patches help.

djbobyd commented 1 year ago

I tested manually the patch but couldn't make it work. The only way I was able to make it work as expected was after I changed the ListenAddress in /etc/xrdp/sesman.ini to 0.0.0.0 I know this might be a security issue and not the best fix, but this was the only thing that worked so far.

drizuid commented 1 year ago

I tested manually the patch but couldn't make it work. The only way I was able to make it work as expected was after I changed the ListenAddress in /etc/xrdp/sesman.ini to 0.0.0.0 I know this might be a security issue and not the best fix, but this was the only thing that worked so far.

wait for the new build, which incorporates the baseimage changes I merged as mentioned in https://github.com/linuxserver/docker-calibre/issues/106#issuecomment-1286049438

that said, we dont test or support podman at all (especially rootless)

wizzy99 commented 1 year ago

Latest build now works.

jaydeethree commented 1 year ago

FYI, even with the latest image (which I've verified contains https://github.com/linuxserver/docker-baseimage-rdesktop/pull/21), this still doesn't work in Podman. I know Podman isn't supported, but I just wanted to mention this in case any other Podman users run into problems. The 6.4.0 build seems to work fine in Podman.

djbobyd commented 1 year ago

I am not sure what the problem with podman/containerd is, but I found a workaround that works good enough in a k8s environment. I am using the lifecycle event hook "postStart" the following way:

    containers:
       - name: calibre
          lifecycle:
            postStart:
              exec:
                command: ['sh', '-c', "sed -i 's/ListenAddress/;ListenAddress/' /etc/xrdp/sesman.ini"]

It is a snippet from the deployment manifest. It's not ideal, but works. Just keep in mind that you are opening a port to the outside world with this. I do not recommend it if your calibre server is used in an insecure environment/network. For my home use where no one except me has access to the home network it seems good enough.

djbobyd commented 1 year ago

that said, we dont test or support podman at all (especially rootless)

I am aware that podman/containerd/cri-o are not supported, but actually I've been running linuxserver images with them for a couple of years already and never had a problem with them until now.

drizuid commented 1 year ago

but actually I've been running linuxserver images with them for a couple of years already and never had a problem with them until now.

I'll start with saying I appreciate you providing your current work-around, thank you!

I'll follow up with saying that while our things MAY have worked on k8s/podman/ because we don't support or test on those platforms, they are not things we will fix. If we break them, they'll stay broken unless someone submits a PR that addresses the issue AND does not cause any impact for things that we do support. We very thoroughly test our PRs and we just don't have anyone on the team willing to put in the effort to test these other things (if you check our issue/pr tracker you'll see why)

thespad commented 1 year ago

What's odd is that we haven't changed the xrdp sesman config, but it could be something that changed with the base move to Jammy.

drizuid commented 1 year ago

I am not sure what the problem with podman/containerd is, but I found a workaround that works good enough in a k8s environment. I am using the lifecycle event hook "postStart" the following way:

    containers:
       - name: calibre
          lifecycle:
            postStart:
              exec:
                command: ['sh', '-c', "sed -i 's/ListenAddress/;ListenAddress/' /etc/xrdp/sesman.ini"]

It is a snippet from the deployment manifest. It's not ideal, but works. Just keep in mind that you are opening a port to the outside world with this. I do not recommend it if your calibre server is used in an insecure environment/network. For my home use where no one except me has access to the home network it seems good enough.

Hello, we found that the lack of this change you show was not in line with some other recent changes we've pushed. The default is supposed to be 0.0.0.0 but it appears that ubuntu is shipping this package with the ListenAddress in that ini as 127.0.0.1 which caused the issue you discovered. This also has the propensity to cause some ipv6 issues and as such, we've addressed it much like you did in your work-around. Please try it out once everything is merged and built!

cbachmann987 commented 1 year ago

I can confirm that 6.7.1 works for me fine in podman. Thanks.

djbobyd commented 1 year ago

I confirm the 6.8.0 is working fine in kubernetes with containerd although, I can see that there must be something else fixed since the ListenAddress line is still uncommented, and yet everything works.

drizuid commented 1 year ago

I confirm the 6.8.0 is working fine in kubernetes with containerd although, I can see that there must be something else fixed since the ListenAddress line is still uncommented, and yet everything works.

hm that's pretty weird, as you can see: https://github.com/linuxserver/docker-baseimage-rdesktop/pulls?q=sesman.ini

and the only change was to comment out the ListenAddress. Is there a particular branch you're pulling?

djbobyd commented 1 year ago

As far as I can tell I am using this one: 

linuxserver/calibre:6.8.0
Digest:sha256:aedc07fd2b242356a1613f1a9def78f9339567388161708da5fd3915d4bac243

which is also the latest for linux/amd64 arch

drizuid commented 1 year ago

I'm at a loss, you see the change for yourself in the PR, it clearly fixed the issue, but im unsure why you see the line uncommented.. that said, i think if podman and k8s are working, im just going to pretend everything is fine and move on :)

djbobyd commented 1 year ago

I am fine with that :)

zephyros-dev commented 1 year ago

I can confirm that 6.7.1 works for me fine in podman. Thanks.

Can you share your run options? I could not get it to work on podman v4.2.1 using 6.7.1 or the 6.8.0 image. The image digest is:

"Digest": "sha256:33e45be98829ae2b9f5e61aab9b77b19d20460ad56e2a3301d208a859e17dbd6",                                                                                                                                                                                                                                                                                             
"RepoTags": [                                                                                                                                                                                                                                                                                                                                                                    
     "lscr.io/linuxserver/calibre:latest",                                                                                                                                                                                                                                                                                                                                       
     "lscr.io/linuxserver/calibre:6.8.0",
     "docker.io/linuxserver/calibre:latest"
]

logs:

[2022-11-08 23:22:31] [Connection 1]  Closing connection with error:  Error: WS was inactive for too long
    at ClientConnection.checkActivity (/gclient/node_modules/guacamole-lite/lib/ClientConnection.js:154:24)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)
[2022-11-08 23:22:31] [Connection 1]  Closing guacd connection
[2022-11-08 23:22:31] [Connection 1]  Client connection closed
guacd[262]: ERROR:      User is not responding.
guacd[262]: INFO:       User "@a0773cb4-ad33-4f38-b134-05c278b22a88" disconnected (0 users remain)
guacd[262]: INFO:       Last user of connection "$4b0900f8-4782-4bad-b9df-a4467e5c75f4" disconnected
guacd[262]: INFO:       Internal RDP client disconnected
guacd[209]: INFO:       Connection "$4b0900f8-4782-4bad-b9df-a4467e5c75f4" removed.
rdpClientConRecv: g_sck_recv failed(returned 0)
rdpClientConRecvMsg: error
rdpClientConCheck: rdpClientConGotData failed
rdpClientConDisconnect:
rdpRemoveClientConFromDev: removing clientCon 0x55fd92d9cff0
cbachmann987 commented 1 year ago

I use something like: 

/usr/bin/podman run \
  --name calibre-main \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Europe/London \
  -e PASSWORD=<hidden> \
  --security-opt seccomp=unconfined \
  -v /srv/calibre/config:/config:Z \
  -v /srv/calibre/books:/books:Z \
  docker.io/linuxserver/calibre:6.7.1

Not sure it if helps

zephyros-dev commented 1 year ago

@cbachmann987 Thanks for the assists. I finally found the problem: I forgot that I turn on the firewalls on my server so I could not reached my custom test ports for the calibre service.