Subject: sane-utils: init script prompts for file removal when status is queried by nonroot user

From: Alexander Rehbein <[email-masked]>
Date: Fri, 31 Oct 2025 18:01:42 +0100

Package: sane-utils
Version: 1.2.1-2
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: [email-masked]

Dear Maintainer,

when running the command '/usr/sbin/service --status-all' as nonroot,
the script hangs inside '/etc/init.d/saned' until I press 'Enter'.
Same for '/usr/sbin/service saned status'.

I would expect the command to just finish outputting all statuses.

It's an easy fix, just add the '-f' flag to the 'rm' command.

I did this and now both commands run through for nonroot without waiting for input.

Thank you

Alexander

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 5 (daedalus)
Release:	5
Codename:	daedalus
Architecture: x86_64

Kernel: Linux 6.1.0-40-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages sane-utils depends on:
ii  adduser                          3.134
ii  debconf [debconf-2.0]            1.5.82
ii  init-system-helpers              1.65.2devuan1
ii  libavahi-client3                 0.8-10+deb12u1devuan1
ii  libavahi-common3                 0.8-10+deb12u1devuan1
ii  libc6                            2.36-9+deb12u13
ii  libelogind-compat [libsystemd0]  246.10-5
ii  libieee1284-3                    0.2.11-14
ii  libjpeg62-turbo                  1:2.1.5-2
ii  libpng16-16                      1.6.39-2
ii  libsane1                         1.2.1-2
ii  libusb-1.0-0                     2:1.0.26-1
ii  libxml2                          2.9.14+dfsg-1.3~deb12u4
ii  update-inetd                     4.53

sane-utils recommends no packages.

Versions of packages sane-utils suggests:
ii  avahi-daemon  0.8-10+deb12u1devuan1
pn  unpaper       <none>

-- Configuration Files:
/etc/init.d/saned changed:
. /lib/lsb/init-functions
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/saned
NAME=saned
DESC="SANE network scanner server"
test -x $DAEMON || exit 0
RUN=no
RUN_AS_USER=saned
. /lib/lsb/init-functions
if [ -f /etc/default/saned ] ; then
    . /etc/default/saned
fi
DAEMON_OPTS="-a $RUN_AS_USER"
set -e
case "$1" in
  start)
	log_daemon_msg "Starting $DESC" "$NAME"
	start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
		--exec $DAEMON -- $DAEMON_OPTS
	log_end_msg $?
	;;
  stop)
	log_daemon_msg "Stopping $DESC" "$NAME"
	start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/$NAME.pid \
		--retry 10 --exec $DAEMON
	log_end_msg $?
	;;
  force-reload)
	# check whether $DAEMON is running. If so, restart
	start-stop-daemon --stop --test --quiet --pidfile \
		/var/run/$NAME.pid --exec $DAEMON \
	&& $0 restart \
	|| exit 0
	;;
  restart)
	log_daemon_msg "Restarting $DESC" "$NAME"
	$0 stop
	$0 start
	;;
  status)
	if [ -s /var/run/$NAME.pid ]; then
            RUNNING=$(cat /var/run/$NAME.pid)
            if [ -d /proc/$RUNNING ]; then
                if [ $(readlink /proc/$RUNNING/exe) = $DAEMON ]; then
                    log_success_msg "$NAME is running"
                    exit 0
                fi
            fi
            # No such PID, or executables don't match
            log_failure_msg "$NAME is not running, but pidfile existed"
            rm -f /var/run/$NAME.pid
            exit 1
        else
            rm -f /var/run/$NAME.pid
            log_failure_msg "$NAME not running"
            exit 1
        fi
	;;
  *)
	N=/etc/init.d/$NAME
	log_failure_msg "Usage: $N {start|stop|restart|force-reload}"
	exit 1
	;;
esac

-- debconf information excluded

---

From: Andrew Bower <[email-masked]>
Date: Sun, 2 Nov 2025 00:12:17 +0000

Hi Alexander,

Some comments as an observer.

> I did this and now both commands run through for nonroot without waiting for input.

I don't like the idea that a status check is destructive but I can see
why the initscript author did that, to clean up inconsistent state. In
that light, I agree your workaround is an improvement.

The root cause of this issue seems to be that saned does not remove
its pidfile. It would be nice to get that fixed upstream.

But we can also improve the issue in the initscript like so:

--- debian/sane-utils.saned.init	2025-11-01 23:30:39.852645419 +0000
+++ /etc/init.d/saned	2025-11-01 23:20:42.507591180 +0000
@@ -47,6 +47,7 @@
   stop)
 	log_daemon_msg "Stopping $DESC" "$NAME"
 	start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/$NAME.pid \
+		--remove-pidfile \
 		--retry 10 --exec $DAEMON
 	log_end_msg $?
 	;;

The init-d-script(5) interpreter actually deletes the pid file
unconditionally so an even better way might be to swap out the entire
initscript with a simpler one using init-d-script.

Out of interest, do you use the saned server?

I suspect most users of this package don't and I was already considering
proposing that the initscript is disabled by default, which would match
the systemd behaviour, which personally I think is the right thing to do
although might not be the majority view in Devuan:

diff --git a/debian/rules b/debian/rules
index 1b0243f..d0ecb43 100755
--- a/debian/rules
+++ b/debian/rules
@@ -148,7 +148,7 @@ ifeq (linux,$(DEB_HOST_ARCH_OS))
 endif
 
 override_dh_installinit-arch:
-       dh_installinit -psane-utils --name=saned
+       dh_installinit -psane-utils --no-enable --name=saned
 
 override_dh_installsystemd-arch:
        dh_installsystemd -psane-utils --no-enable --name=saned

-- 
Andrew

---

From: Mark Hindley <[email-masked]>
Date: Sun, 2 Nov 2025 08:03:31 +0000

Control: tags -1 debian

Alexander and Andrew,

Many thanks for this.

> But we can also improve the issue in the initscript like so:

Yes, that seems a good suggestion.

However, src:sane-backends is not forked in Devuan and we use Debian's packages
directly without recompilation. This issue will be evident on a Debian
non-systemd install.

Can you report with your suggested patch(es) to Debian's BTS, please?

Thanks

Mark

---

From: Alexander Rehbein <[email-masked]>
Date: Mon, 3 Nov 2025 23:55:20 +0100

Hi Mark,

yes I could look into it (not that experienced with all the workflows/I'll
have to look things up first).

I don't completely understand though... it seemed to me like Debian wasn't
supporting SysVInit anymore, so are they even thinking about putting any
work into fixing init scripts? It doesn't look like they care really, at
least for saned I have also noticed that statuses aren't reported correctly
when running `service --status-all` without any root privilege. And I think
some other things also weren't working correctly, like some scripts
wouldn't work but return 0 without root or something among those lines.

Thank you

Alexander

---

From: Andrew Bower <[email-masked]>
Date: Mon, 3 Nov 2025 23:10:57 +0000

>    have to look things up first).

Alexander, I'll be happy to support you on the Debian bug when the time
comes if you need it (I wrote the saned integration for runit-services
and contributed a fix upstream to help with daemon management and
cleanup)! (X-Debbugs-CC: is a handy way to involve someone else.)

>    work into fixing init scripts? It doesn't look like they care really,

It's not quite like that. Mark maintains sysvinit in Debian so at least
one person cares! It's not compulsory for maintainers to maintain
initscripts but many do and we shouldn't assume hostility. They may not
even realise there are users for them and it often just needs users to
contribute to maintaining them. I had some improvements accepted days
ago for a package that at one point had removed them.

> at
>    least for saned I have also noticed that statuses aren't reported
>    correctly when running `service --status-all` without any root privilege.
>    And I think some other things also weren't working correctly, like some
>    scripts wouldn't work but return 0 without root or something among those
>    lines.

A lot of the initscripts are pretty horrendous... or at least are
overcomplicated by predating improvements that can make them easier to
write well.