sbs20 / scanservjs

SANE scanner nodejs web ui
https://sbs20.github.io/scanservjs/
GNU General Public License v2.0
712 stars 140 forks source link

Docker - sane-airscan won't detect + dbus_connection_send while troubleshooting #628

Open rgriffogoes opened 1 year ago

rgriffogoes commented 1 year ago

Describe the bug I'm unable to get scanservjs to detect my HP Deskjet 3755 using sane-airscan, using Docker within in WSL. The idea is to try it out on my powerful desktop before put it to run with docker compose in my NAS.

The web server seems to work fine.

If I run the standard image using:

sudo docker run -d -p 8080:8080 -e AIRSCAN_DEVICES='HP = http://192.168.1.150/eSCL, eSCL' --name scanservjs-container sbs20/scanservjs:latest

I simply get a no devices found, and if I run scanimage -L in the container it will execute and say nothing found.

sane + airscan + WSL + docker works

I was able to spin up a Ubuntu docker container in WSL, install sane + sane-airscan and after some configurations I was able to get it working.

The main configuration I had to change in my airsane test was to specify the device directly and for some reason I had to disable the discover (docker in WSL likely messes up network stack). So in /etc/sane.d/airscan.conf I have:

[devices]
HP = http://192.168.1.150/eSCL, eSCL
....
[options]
discovery = disable

Trying to have the "discovery disable" in scanservjs container

As changing the code to add a new AIRSCAN_OPTIONS='discovery = disable' parameter was straightforward, I decide to try my luck.

But If I build the image myself with docker build -t scanservjs_custom . and try to run it using

sudo docker run -d -p 8080:8080 -v /var/run/dbus:/var/run/dbus -e AIRSCAN_DEVICES='HP = http://192.168.1.150/eSCL, eSCL' --name scanservjs-container scanservjs_custom

I get the following error (in the UI and if I bash into the container and try scanimage)

Command failed: /usr/bin/scanimage -L\ndbus[47]: arguments to dbus_connection_send() were incorrect, assertion \"connection != NULL\" failed in file ../../../dbus/dbus-connection.c line 3307.\nThis is normally a bug in some application using the D-Bus library.\n\n  D-Bus not built with -rdynamic so unable to print a backtrace\nAborted\n

In the container, the resulting configuration file seems identical to my Ubuntu test, so the new parameter seems fine. I tried without my changes as well with same error. I guess there is some issue with my building process.

This seems related to #450, #547 and #551 but not quite the same.

I don't think there is an issue with the generated scanimage command (e.g.: ; character), and following the suggestions (using HP, using privileged, mounting/not mounting dbus) got same results.

Building the latest version and the 2.27.0 tag (which should match the released image) gets to same error.

I don't know what dbus really is, so can't really see what is the next troubleshooting step.

Any tips on how to proceed?

Thanks!

Server

Logs

[2023-08-11T04:06:41.926Z] INFO (Process): { execute: '/usr/bin/scanimage -L' }
[2023-08-11T04:06:41.939Z] ERROR (Http): Error: Command failed: /usr/bin/scanimage -L
dbus[24]: arguments to dbus_connection_send() were incorrect, assertion "connection != NULL" failed in file ../../../dbus/dbus-connection.c line 3307.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

    at ChildProcess.exithandler (node:child_process:402:12)
    at ChildProcess.emit (node:events:513:28)
    at maybeClose (node:internal/child_process:1100:16)
    at Socket.<anonymous> (node:internal/child_process:458:11)
    at Socket.emit (node:events:513:28)
    at Pipe.<anonymous> (node:net:301:12) {
  code: 134,
  killed: false,
  signal: null,
  cmd: '/usr/bin/scanimage -L',
  stdout: '',
  stderr: 'dbus[24]: arguments to dbus_connection_send() were incorrect, assertion "connection != NULL" failed in file ../../../dbus/dbus-connection.c line 3307.\n' +
    'This is normally a bug in some application using the D-Bus library.\n' +
    '\n' +
    '  D-Bus not built with -rdynamic so unable to print a backtrace\n' +
    'Aborted\n'
}
rgriffogoes commented 1 year ago

Manually editing the file /etc/sane.d/airscan.conf and setting discovery to disable, restarting the container (couldn't figure out how to restart saned) it was able to detect and use the scanner.

So my minor change to enable env parameters to set these would come handy, as now if I recreate the container my change is lost.

Then the mystery of why my images fail with dbus errors is still a mistery.

Eventually I added to my NAS setup, using docker compose, and without any mention of dbus config (but docker is running as root).

rubiktubik commented 10 months ago

I had the same problems that my printer is not detected automatically. Now it works thanks to your hints @rgriffogoes 👍 .

What I did:

  1. Used the default command to start the container:

    docker run -d \
    -p 8080:8080 \
    -v /var/run/dbus:/var/run/dbus \
    --restart unless-stopped \
    --name scanservjs-container \
    --privileged sbs20/scanservjs:latest
  2. install nano with: apt update && apt install nano

  3. Edited /etc/sane.d/airscan.conf to disable discovery and add my device

    [devices]
    HP = http://192.168.1.150/eSCL, eSCL
    ....
    [options]
    discovery = disable
  4. Restart sane

    service saned restart
sbs20 commented 9 months ago

I think there are two different issues here (though perhaps the second is a workaround to the first)

dbus

This is tricky. And it's not helped by the fact that this is at the very edge of my knowledge - if I sound authoritative on this, don't attach too much weight!

Auto-discover uses a multicast - essentially it pings the whole subnet and waits for a response to see what services are available. This is underpinned by bonjour and avahi in linux and avahi uses dbus (this is the hand wavy bit) and why we have to map them. You may need to ensure that avahi is installed on the host in order to work (see SO post).

My question is - when you built your ubuntu container, what was in it (i.e. what did you install exactly) and did auto-discover work? If it did not, then we're no further forward - but if it did then something is missing from the mainline image and I'd like to fix it.

Also - were both containers in the same host (as in - the same WSL instance)? If not, were there any differences as to what was installed in the hosts?

Fixing airscan.

There is an easier way to resolve this - just volume map the airscan conf. The default config is all commented out so there's no problem merging anything. The host will just overwrite the guest. So no need to shell inside the container and do anything - just use the default image.

# Create your airscan config
cat > ./airscan.host.conf << EOF
[devices]
HP = http://192.168.1.150/eSCL, eSCL

[options]
discovery = disable
EOF

# Now map it
docker run -d \
  -p 8080:8080 \
  -v ./airscan.host.conf:/etc/sane.d/airscan.conf \
  --restart unless-stopped \
  --name scanservjs-container \
  --privileged sbs20/scanservjs:latest

Since you're not using autodiscovery, you don't need to map dbus.