Devuan bug report logs - #749
initscripts: /etc/init.d/halt calls halt with unsupported options

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: initscripts
Version: 3.06-2devuan1
Severity: normal
X-Debbugs-Cc: none, Olaf Meeuwissen <paddy-hack@memberr.fsf.org>

Dear Maintainer,

Every time I `poweroff` my machine, I see error message flash by that
complain about `halt` being called with unsupported options.  I think
I have tracked this down to /etc/init.d/halt making blind assumptions
about the options supported by the `halt` command.

Said command may be provided by any of a number of packages.  A quick
`apt-file search sbin/halt` turns up

  $ apt-file search sbin/halt
  bfh-container: /sbin/halt
  finit-sysv: /sbin/halt
  molly-guard: /sbin/halt
  progress-linux-container: /sbin/halt
  runit-init: /sbin/halt
  systemd-sysv: /sbin/halt
  sysvinit-core: /sbin/halt

Mine happens to be

  $ ls -l /sbin/halt
  lrwxrwxrwx 1 root root 19 Feb 10 03:45 /sbin/halt -> /lib/runit/shutdown

where the symlink target is from the runit package.  According to the
manual page, my halt command only supports -f, -w and -n short options.

The /etc/init.d/halt script may invokes the halt command with -d and -f
options and may add any of -i, -p and -h.

BTW, I also have runit-init installed which provides the `poweroff` and
`halt` commands that get executed.  Seeing that runit-init depends on
initscripts one could argue that runit-init should support those options
in which case feel free to forward this to that package (in the Debian
BTS).  From past experience, its maintainer is open to init freedom ;-)

If not a runit-init issue, this may still be worthwhile to upstream to
the Debian BTS for initscripts.  Even the systemd-sysv `halt` does not
claim to support -i or -h options in its manual page :-o

-- System Information:
Architecture: x86_64

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages initscripts depends on:
ii  sysv-rc         3.06-2devuan1
ii  sysvinit-utils  3.06-2devuan1

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.6-1
pn  psmisc     <none>

initscripts suggests no packages.

-- no debconf information

Hope this helps,
--
Olaf Meeuwissen

Message #8 received at 749@bugs.devuan.org (full text, mbox, reply):

Olaf,

On Wed, Mar 08, 2023 at 08:44:01PM +0900, Olaf Meeuwissen wrote:
> Package: initscripts
> Version: 3.06-2devuan1
> Severity: normal
> X-Debbugs-Cc: none, Olaf Meeuwissen <paddy-hack@memberr.fsf.org>
> 
> Dear Maintainer,
> 
> Every time I `poweroff` my machine, I see error message flash by that
> complain about `halt` being called with unsupported options.  I think
> I have tracked this down to /etc/init.d/halt making blind assumptions
> about the options supported by the `halt` command.

Thanks. We keep bumping into issues similar to this with the different halt
implementations.

I don't immediately have a really good solution.

> Said command may be provided by any of a number of packages.  A quick
> `apt-file search sbin/halt` turns up
> 
>   $ apt-file search sbin/halt
>   bfh-container: /sbin/halt
>   finit-sysv: /sbin/halt
>   molly-guard: /sbin/halt
>   progress-linux-container: /sbin/halt
>   runit-init: /sbin/halt
>   systemd-sysv: /sbin/halt
>   sysvinit-core: /sbin/halt
> 
> Mine happens to be
> 
>   $ ls -l /sbin/halt
>   lrwxrwxrwx 1 root root 19 Feb 10 03:45 /sbin/halt -> /lib/runit/shutdown
> 
> where the symlink target is from the runit package.  According to the
> manual page, my halt command only supports -f, -w and -n short options.

My gut reaction is that runit's halt should either support the sysvinit options
even if noop.

Lorenzo,

I have no real experience of runit yet. What is the relationship between it an
initscripts? When are the initscripts used? Is there something you can do within
src:runit to avoid this?

Thanks

Mark

Message #13 received at 749@bugs.devuan.org (full text, mbox, reply):

Hello,

On Wed, 8 Mar 2023 12:43:30 +0000
Mark Hindley <mark@hindley.org.uk> wrote:

> > where the symlink target is from the runit package.  According to
> > the manual page, my halt command only supports -f, -w and -n short
> > options.
> 
> My gut reaction is that runit's halt should either support the
> sysvinit options even if noop.

The current behavior of runit's halt is that options -d -h -p -i
are ignored except that a warning is printed (the exit status is zero).
They are not really noop, since in the original sysvinit implementation
each of -d -h -p -i imply halting/poweroff the system, so that's what
runit's halt does after "ignoring" such options.
I've tested in the past that if I turn -d -h -p -i into noop
the switch sysvinit --> runit-init is broken, so I don't want to do
that.
What is left on runit's side is that I can silence the warning (but I
don't think is a good behavior for a program to silently ignore some
options - it can be documented in the man page though) or add a special
case in 'run_sysv_script' so that 'reboot' and 'halt' scripts are
skipped during runit shutdown sequence.

> 
> Lorenzo,
> 
> I have no real experience of runit yet. What is the relationship
> between it an initscripts? When are the initscripts used?

Runit is currently borrowing from sysvinit (initscripts package)
scripts to initialize and shutdown the system; it runs sequentially
scripts from /etc/rcS.d/ to boot the system and scripts from /etc/rc0.d/
or /etc/rc6.d/ for shutdown/reboot.

> Is there
> something you can do within src:runit to avoid this?
I think reassigning this to runit as Debian bug with severity minor is
appropriate.

Lorenzo

> 
> Thanks
> 
> Mark

Message #18 received at 749@bugs.devuan.org (full text, mbox, reply):

> On Wed, 8 Mar 2023 12:43:30 +0000
> Mark Hindley <mark@hindley.org.uk> wrote:

> > Is there
> > something you can do within src:runit to avoid this?
> I think reassigning this to runit as Debian bug with severity minor is
> appropriate.
> 
I've just opened a bug against runit-init
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032943
I think this bug can be closed

Lorenzo

Message #21 received at 749@bugs.devuan.org (full text, mbox, reply):

Control: tags -1 debian
Control: forwarded -1  https://bugs.debian.org/1032943

On Tue, Mar 14, 2023 at 02:40:45PM +0100, Lorenzo wrote:
> 
> > On Wed, 8 Mar 2023 12:43:30 +0000
> > Mark Hindley <mark@hindley.org.uk> wrote:
> 
> > > Is there
> > > something you can do within src:runit to avoid this?
> > I think reassigning this to runit as Debian bug with severity minor is
> > appropriate.
> > 
> I've just opened a bug against runit-init

Lorenzo,

Thanks. Setting tags and forwarded.

Mark

Message #37 received at 749-done@bugs.devuan.org (full text, mbox, reply):

Version: 2.1.2-55

Send a report that this bug log contains spam.