avahi-daemon not running

[dantebarba]

I started the daemon with docker using the same command line from the readme.md. When I try to access any kind of option in the control panel I get 500 Server Error. I checked the logs and I saw this:

Unable to communicate with avahi-daemon: Daemon not running

I'm using Debian (open media vault).

Docker version 18.09.4, build d14af54 Kernel: 4.19.0-0.bpo.2-amd64 Connected printer is a Samsung SCX-4200.

[jaymoulin]

When I try to access any kind of option in the control panel I get 500 Server Error.

How did you perform this? Did you docker exec cloudprint configure open before trying to configure something?

[dantebarba]

Yes I did. Maybe it's because OMV is already running avahi on the host?.

PS: this image includes both CUPS and Google Cloud Print connector right?

[jaymoulin]

Docker purpose is to isolate so, no matter if avahi is running or not on the host. This repository provides fully working docker images and you don't have to do anything else than what's described in the README file.

How are you trying to configure your container?

[dantebarba]

I first tried using a docker-compose configuration based on your docker run line:

docker run -d --privileged --restart=always -v /dev/bus/usb:/dev/bus/usb -v "$HOME/.cloudprint/":/root --name cloudprint -e CUPS_USER_ADMIN=admin -e CUPS_USER_PASSWORD=password -p 631:631 jaymoulin/google-cloudprint

version: '2'

services:
  cloudprint:
    image: jaymoulin/google-cloudprint
    container_name: cloudprint
    restart: unless-stopped
    privileged: true
    volumes:
      - /dev/bus/usb:/dev/bus/usb
      - ${CLOUDPRINT_CONFIG}/cups:/etc/cups
      - ${CLOUDPRINT_CONFIG}/credentials:/root
    environment:
      CUPS_USER_ADMIN: admin
      CUPS_USER_PASSWORD: ${CUPS_USER_PASSWORD}
    ports:
      - 631:631
    labels:
      - "traefik.docker.network=main"
      - "traefik.enable=true"
      - "traefik.basic.frontend.rule=Host:printer.${DOMAIN_URL}"
      - "traefik.basic.port=631"
      - "traefik.basic.protocol=http"
    networks:
      - main

networks: 
  main:
    external: true

The container didn't start (it died exiting with code 0). So I removed the container and started using the readme line (docker run...). Container starts, control panel starts, but log shows avahi is not running.

[jaymoulin]

avahi is not required. It's only a service to provide DNS but you don't need it.

If your control panel starts, then you don't have any problem :)

[dantebarba]

Yes, but I'm getting 500 server error on every page.

1. start the image:

root@papini:~# docker run -d --privileged --restart=always -v /dev/bus/usb:/dev/bus/usb -v "$HOME/.cloudprint/":/root --name cloudprint -e CUPS_USER_ADMIN=admin -e CUPS_USER_PASSWORD=password -p 631:631 jaymoulin/google-cloudprint
df999ee5583926a794473775bf0bf10082e3c1670936827e20d0056afa5ff26c

2. Execute open config:

root@papini:~# docker exec cloudprint configure open
chpasswd: password for 'admin' changed

3. Open CPanel

4. Click on add printer, or any kind of hyperlink

[jaymoulin]

Cupds official documentations says it could be due to your rights (https://www.cups.org/doc/man-cupsd-logs.html)

Could you check your volumes are created with correct rights? (cups user in this docker image is root by default)

[dantebarba]

Just one volume is created:

drwxr-xr-x 2 root root 4096 May 26 13:11 .cloudprint

Rights look ok to me, owned by root and was created by the container, so container is running on root.

[dantebarba]

log shows the following:

E [26/May/2019:16:56:56 +0000] Unable to open listen socket for address [v1.::1]:631 - Address not available.
E [26/May/2019:16:58:08 +0000] Unable to communicate with avahi-daemon: Daemon not running

[jaymoulin]

Do you have a cupsd already running on your host?

[dantebarba]

Do you have a cupsd already running on your host?

Nope. cupsd is not running, not even installed

Any chance to start the container with debug, I feel the log is sort of empty.

[jaymoulin]

You can "connect" to the container the check what you want with docker exec -ti cloudprint sh. You'll probably find logs in /var/log/cups

[dantebarba]

I did,

/var/log/cups # cat error_log 
E [26/May/2019:17:08:34 +0000] Unable to open listen socket for address [v1.::1]:631 - Address not available.
E [26/May/2019:17:10:34 +0000] Unable to communicate with avahi-daemon: Daemon not running

[dantebarba]

Looks like something related to ipv6?.

https://www.linuxquestions.org/questions/slackware-14/disabling-ipv6-seems-to-break-cups-4175518566/

[jaymoulin]

Your link is from 2014 and their clues are based on a previous revision (https://github.com/apple/cups/issues/4305). BTW, cupds configuration files in the docker image are set to use ipv4.

Could you try creating the container without the .cloudprint volume?

[dantebarba]

I'm sorry, but same issue :/

[dantebarba]

When I execute docker exec cloudprint configure open the container stops running, is that normal or something is not working correctly?. With the restart always flag I didn't noticed it, but now I deleted the flag and I have to manually start the container.

[jaymoulin]

When I execute docker exec cloudprint configure open the container stops running, is that normal or something is not working correctly?. With the restart always flag I didn't noticed it, but now I deleted the flag and I have to manually start the container.

It's the expected behaviour as cupds needs to be restarted to handle its new configuration

[dantebarba]

Okay, now:

1. No volumes, not even /dev/bus/usb
2. No --privileged flag

Same Internal server error.

[dantebarba]

Hmm, tested the image on my VPS server running Ubuntu 16.04 LTS and it's working. Obviously I don't have a printer there but CPanel loads ok.

So It's something with my local NAS that the container doesn't like. Unfortunately there is no log.

[dantebarba]

The log from the VPS it's exactly the same as from the NAS. The mystery deepens.

[jaymoulin]

Your VPS and your NAS must have different architectures and probably use different docker image. You should be able to determine this with this command : docker inspect cloudprint --format='{{index .Config.Labels.version}}'

[dantebarba]

NAS:

0.4.3-amd64

VPS:

0.4.3-amd64

[dantebarba]

Got it, using LogLevel debug the error is not obfuscated anymore.

D [26/May/2019:18:35:17 +0000] [CGI] Started /usr/lib/cups/cgi-bin/admin.cgi (PID 15)
I [26/May/2019:18:35:17 +0000] [Client 1] Started "/usr/lib/cups/cgi-bin/admin.cgi" (pid=15, file=10)
D [26/May/2019:18:35:17 +0000] [Client 1] Waiting for CGI data.
D [26/May/2019:18:35:17 +0000] [CGI] execv failed: Permission denied
D [26/May/2019:18:35:17 +0000] PID 15 (/usr/lib/cups/cgi-bin/admin.cgi) stopped with status 113 (Permission denied)
D [26/May/2019:18:35:17 +0000] [Client 1] CGI data ready to be sent.
D [26/May/2019:18:35:17 +0000] [Client 1] con->http=0x55f670144340
D [26/May/2019:18:35:17 +0000] [Client 1] cupsdWriteClient error=0, used=0, state=HTTP_STATE_GET_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=2147483647, response=0(), pipe_pid=15, file=10
D [26/May/2019:18:35:17 +0000] [Client 1] Waiting for CGI data.
D [26/May/2019:18:35:17 +0000] [Client 1] cupsdSendHeader: code=500, type="text/html", auth_type=0
D [26/May/2019:18:35:17 +0000] [Client 1] Waiting for request.
D [26/May/2019:18:35:17 +0000] [Client 1] Closing because Keep-Alive is disabled.
D [26/May/2019:18:35:17 +0000] [Client 1] Closing connection.

[jaymoulin]

Should resolve your issue : https://stackoverflow.com/questions/32462340/cups-permission-denied.

Seems this is not related to the image, I can't fix anything

[dantebarba]

But /usr/lib/cups/cgi-bin/admin.cgi it's inside the image and already has root ownership. Why it's giving permission denied when it has root permissions on everything

[dantebarba]

It's still giving me permission denied. Doesn't make any sense. I already did:

1. id -u --> 0
2. chown -R 0:0 /usr/lib/cups

Nothing, still error 113.

[dantebarba]

I'm giving up. Same issue with this image: https://github.com/thbe/docker-cups

[dantebarba]

Ended up installing CUPs outside Docker and using a GCP Connector image. It was not the intended solution but given that I can't make CUPs work with Docker, it's the best I cloud achieve.

Anyway thanks @jaymoulin for the help