anujdatar / cups-docker

CUPS server running in a docker container
GNU General Public License v3.0
93 stars 29 forks source link

CUPS Fails to Detect Printer After Power Off #15

Open 0elek opened 6 months ago

0elek commented 6 months ago

Currently, when the printer is turned off, cups is unable to detect it when I turn it back on.

It works fine when i restart the docker container, so I think its having trouble finding the /dev/usb/[], since it changes when the printer is reconnected container host's OS.

Not sure that I set up something wrong, or its an issue with the container.

docker-compose.yml:

services:
    cups:
        image: anujdatar/cups
        container_name: cups
        restart: always
        ports:
            - "631:631"
        devices:
            - /dev/bus:/dev/bus
            - /dev/usb:/dev/usb
        environment:
            - CUPSADMIN=admin
            - CUPSPASSWORD=password
            - TZ="Europe/Warsaw"
        volumes:
            - ./data:/etc/cups

data/printers.conf:

# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
NextPrinterId 2
<Printer EPSON_L310_Series>
PrinterId 1
UUID urn:uuid:aa358d43-05a5-31db-6324-f9e9d4e078b6
Info EPSON L310 Series
Location
MakeModel Epson L310 - CUPS+Gutenprint v5.3.4
DeviceURI usb://EPSON/L310%20Series?serial=56484D4B3032353618
State Idle
StateTime 1712484122
ConfigTime 1711806586
Type 8425484
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
</Printer>
anujdatar commented 6 months ago

Hi,

Sorry about that. I've been meaning to reply, but I haven't had time to really look into it. But you are correct, I have also experienced this in the past.

The container doesn't always recognise the printer, after the printer is turned OFF then ON. I had tried to avoid this by passing the entire /dev/usb device, instead of a specific port. But it doesn't always work as intended.

I typically have a push-button connected to my RPi's gpio that just restarts this container.

I'll try to take a look at the issue in detail and see what can be done. Can't give you a timeline, but I'll definitely take a look at it. It's something I need to fix anyway. Thanks for reminding me.

mx3coding commented 4 months ago

This is happening with me too.

It is possible to add an workaround, where the printer USB events are listened and if an "on/off" event occur then restart the docker-CUPS service?

anujdatar commented 4 months ago

This could work, but then, if the a printer's power is turned off, and it does not come back on, you could potentially get stuck in a restart-loop. Plus I am not sure how you would run a daemon like that unless you just run a checking script at regular intervals, systemd is typically not used in containers iirc.

mx3coding commented 4 months ago

You are right, this could lead to other issues...

About the restart-loop, my only idea is to create a variable (linked to a checkbox) where you need to be sure if you want to enable it or not, knowing the risks.

0elek commented 4 months ago

i think first we should find out why does to container loses the usb device, cups on bare metal can handle power state change

mx3coding commented 4 months ago

We managed to put a udev rule to monitor USB changes and restart the container. It not the solution for the "why the docker/container loses the connectivity to the device", but works for our needs.

If someone needs it, I detailed the solution here: https://superuser.com/q/1849642/853051

anujdatar commented 4 months ago

Yeah, that was my first thought too, but that's a solution outside the container. So I didn't want to make that the go to method. But yeah, that's a fix for now.

I have an idea I want to explore within the container, for restarting the cups service. I will try it tomorrow and keep you posted.

mx3coding commented 4 months ago

Alright, I will be watching your project.

I have zero to none experience with docker, but if I learn something, I will share here.

0elek commented 4 months ago

this looks helpful but i think we need to run this outside of the container,

Also privileged: true seems to be able to forward the usb after on/off but the id changes, so adding a udev rule(inside the container) should work then? But for that we need somehow know some information like manufacturer and device id. which we can get from the printers.conf.

this looks like a way if somebody wants to fix it.