Usb printers power off and avahi-deamon #35
Comments
|
The message you mentioned appears from time to time. Does it work when you restart the container (after turning on the printer)? From time to time I too have issues with the docker container, but after I restart it, it usually works again. Sorry that I don't have a solution for you. The inner workings of cups (and why it would "forget" the printer when it's off) is a mystery to me. |
|
I did some extra work and investigation. Actually, if I only restart the container, it's not enough. I need to remove the printer on the docker-compose service environment variables, the start it again and add the printer again. This makes the printer available everywhere |
|
That seems strange. If you've configured the printer through environment variables it should be added/setup with every start of the container. Can you maybe share your environment variables that you're using to setup the printer? |
|
Sure. I can share my docker-compose configuration: |
|
Hmm, this lgtm. The
Then at least the printer should be configured in CUPS (not necessarily in Avahi yet). From your initial post: I just double checked the permission denied message of Avahi and I was mistaken - I don't see that in my logs so maybe this is causing issues, but if so, it should only prevent the printer from appearing for AirPrint. I am running the docker container "privileged", so that might also be worth a try if that solves the issue. As I personally don't use docker-compose, maybe you want to try if it works with pure docker. If so, then likely docker-compose does sth. differently which causes the issue. |
|
I see those messages too. I checked again and I noticed that if I run the docker and the printer is off, then the CUPS server displays the connection as |
|
So, the missing permanent storage should not be the issue because as long as the container is running the data is there. Whereas when the container is starting while the printer is off - it makes sense that it won't work. I probably would do the following:
I do have an USB printer, but so far I haven't hooked it directly to the container. As I don't know if I will find time to play with that setup, I can offer to do a debug session together: DrPsychick -AT- drsick.net - I can invite you to my slack to chat or we can meet to share screens. |
|
Sorry, it took me a while to be able to check all your steps. Also, I apologize for the long post, but I'm trying to help myself but also other users. I tried all steps (1 to 4) those are the behaviors:
which looks like a double printer for no reason... Last comment on the permanent storage. My understanding, so far, is that once the printer goes down (or the docker, which might happen), configuration or temporary files are not ok anymore. In fact, some similar logs are also present when the container restart (with the printer still on): |
|
What intrigued me is the "Dirty files" so I googled a bit and found some interesting posts, see below. As you seem to have two printers after turning it back on and/or restarting, I would try to delete the printer before adding it: This might hopefully also cleanup / remove any "dirty files" of the printer. When you're just restarting the container, the changed files should remain, so the "stuck" state remains as well. So the other option could be to delete and recreate the container, because then there are no leftovers from previous runs and the printer gets added for the first time which seems to have worked. PS: thank you for all the details Alessandro, I see it the same way that this might help other people, so I thank you also in their name! |
|
Actually, I solved one thing and I'm still struggling with the other one. Regarding the null file, it is mandatory to add the -v option to the Regarding the on and off, I found this post. Unfortunately, I'm still not able to make it work because the |
|
Does it work, when you add those udev rules mentioned in the post? You could mount them from the host for testing so that they survive a restart of the container. If so, we only need to find a way to make that configurable through ENV, so that it may work for others as well. |
|
I guess I solved the mystery. Basically, I noticed that despite any attempt the Also based on my previous comment, I also attached in the volumes section the |
|
I also encountered a similar problem. Whenever I turned off the printer and turned it on again, I was prompted to Waiting for printer to become available when printing.I need to restart docker. Is there any solution? |
|
@master-ang did you try what I suggested before? |
|
/dev/bus/usb:/dev/bus/usb is working. Now I can restart the printer without restarting the container. Thank you~ I hope that @DrPsychick will improve in the next version. |
|
As this depends on the users setup, the only thing I did now was mentioning it in the Readme (linking to this thread). Any user can mount volumes into the existing container to make USB printers work nicely, so I don't see the need to adjust the image itself. |
|
but in QNAP ContainerStation it's not a option. I can't mount root volumes in the GUI. So, either I use the command line method, or I create a symbolic link to solve this indirectly.I hope this mount can be built into the image, so that it can be a lot more convenient. |
|
I understand. However, the image is a docker image. Any integration with QNAP (which I'm using myself) or other specific integrations is not part of the image and never will be. I use my ansible role https://github.com/DrPsychick/ansible-docker to "deploy" the docker container to my QNAP. That makes it quite easy to maintain and I only use the UI rarely. FYI: my containers:
cups:
hosts: ["neb"]
name: "cups"
basedir: "/share/VMs/docker"
directory: "cups"
owner: "admin"
group: "administrators"
image: "drpsychick/airprint-bridge"
version: "latest"
pull: yes
create: yes
restart: yes
cleanup: yes
templates:
cupsenv: { name: "cups.env", mode: "0644" }
# reuses network of dnsmasq-zion-neb!
pre_command: "if [ -z \"$(docker network ls | grep qnet-static-bond0-dnsmasq)\" ]; then docker network create --driver=qnet --ipam-driver=qnet --ipam-opt=iface=bond0 --subnet 192.168.1.0/24 --gateway 192.168.1.1 qnet-static-bond0-dnsmasq; fi"
create_parameters: "--network qnet-static-bond0-dnsmasq --ip 192.168.1.201 --dns 192.168.1.254 --hostname cups.zion --env-file cups.env --privileged --memory 200m -p 137:137/udp -p 139:139/tcp -p 445:445/tcp -p 631:631/tcp -p 5353:5353/udp"
restart_policy: "always"
ip: 192.168.1.201 |
Please let us know if it keeps working. As I was saying, the AirPrint part is still not stable on my side, and it does not pick the printer all the time. |
|
It keeps working ， I often turn off the printer for days, and when I turn it on again it airprints fine. |
|
Just to check it, is it your configuration in the docker-compose like this: |
|
i just mount dev/bus/usb |
|
FYI as it might also help with this issue: I just merged #40 which ensures avahi is always running. |
|
closing this: it's documented in the readme and has proven to work. If you disagree, feel free to reopen or open another issue. |
|
I have some good news to share: the issue has been resolved! Do you remember when I mentioned that I couldn't add my USB printer? I looked up some information online and found out that it was because I hadn't mapped the /dev/usb folder in the system. But suddenly, mapping only /dev/bus couldn't find the printer anymore (it used to work perfectly before). Additionally, I used your latest version “latest-20250124”， and duplex printing worked fine, so the issue wasn't with your software but with my configuration. I deeply apologize for wasting your precious time. However, it was through our joint testing, repeatedly deleting and creating docker, that I discovered the unmapped issue. Otherwise, since printing was working normally, I probably wouldn't have thought it was due to the unmapped folder. I think you can cancel the duplex version because the original version is also OK. Thank you again! And Happy New Year! |
I'm using the docker with happiness until I turn off the USB printer (a Canon MP240 if useful) but not the server. Then I still spend hours trying to make it work (putting the printer properly on the network again).
I noticed that in logs if I restart the server, I find the following error:
Am I doing something wrong? Should it be fine to power off the printer while the server is still running?
The text was updated successfully, but these errors were encountered: