Silent or move to /dev/null alsactl restore out

Silent or move to /dev/null alsactl restore out

[lumaro.disroot.org via supervision]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Hi, all.
----------------
  $ doas alsactl restore
alsa-lib parser.c:2796:(load_toplevel_config) Unable to find the 
top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1554:(snd_use_case_mgr_open) error: failed to import 
hw:0 use case configuration -2
alsa-lib parser.c:2796:(load_toplevel_config) Unable to find the 
top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1554:(snd_use_case_mgr_open) error: failed to import 
hw:1 use case configuration -2

/home/luis
  $ doas alsactl restore 2>/dev/null

/home/luis
  $ cat /etc/s6/sv/alsa/up
#!/bin/execlineb -P
if -t { test -e /var/lib/alsa/asound.state }
fdmove -c 2 1
exec alsactl restore
----------------

==> fdmove -c 2 1 dont work.

What am I doing wrong? Any ideas? Thanks!
Luis.

Re: Silent or move to /dev/null alsactl restore out

[Laurent Bercot]

>What am I doing wrong? Any ideas? Thanks!

  1. What exactly are you trying to do?
  2. What results did you get? (you apparently posted this, but without
context, it's difficult to tell what is relevant.)
  3. What results did you expect instead?


 > $ cat /etc/s6/sv/alsa/up
 > #!/bin/execlineb -P
 > if -t { test -e /var/lib/alsa/asound.state }
 > fdmove -c 2 1
 > exec alsactl restore

  - You do not need a shebang in an up script. Up scripts are not
executable files. If you change the interpreter in the shebang, the
up script will *still* be processed by execlineb.
  - You do not need an "exec" command. exec is implicit in an execline
script.
  - Your up script is behaving differently depending on whether the
result of the test is true or false. The "alsactl restore" command
may or may not be called, depending on an external property (whether
the asound.state file exists or not). This means that your machine
state after boot is not guaranteed; this is generally a bad idea.

--
  Laurent

Re: Silent or move to /dev/null alsactl restore out

[Alexis]

"Laurent Bercot" <ska-supervision@skarnet.org> writes:

> You do not need a shebang in an up script. Up scripts are not
> executable files. If you change the interpreter in the shebang, 
> the
> up script will *still* be processed by execlineb.

i feel like this might possibly be a reason why a number of people 
assume that _all_ s6-ecosystem scripts have to be execline 
scripts. A `run` script in an s6 servicedir can be any executable 
file, but an s6-rc `up` script for a oneshot (which i think many 
people might feel is roughly similar to a `run` script, in that it 
specifies a particular program to run) is always parsed by 
execlineb. Of course, that doesn't mean that one can't call some 
other interpreter from the execline script, as you note in the 
s6-rc-compile documentation:

> They can be written in any scripting language by invoking the 
> interpreter directly: for instance ‘/bin/sh -c “script”’, where 
> script is a shell script.

However, while it's true that in both s6 and s6-rc, use of 
execline is not _ultimately_ required, in the s6-rc `up` context, 
one _does_ have to at least use execline to call the preferred 
interpreter with the relevant script.


Alexis.

Re: Silent or move to /dev/null alsactl restore out

[Carlos Eduardo]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

`fdmove -c 2 1` is equivalent to shell `2>&1`. You're looking for `redirfd
-w 2 /dev/null`.

Em sáb., 30 de nov. de 2024, 03:54, lumaro.disroot.org via supervision <
supervision@list.skarnet.org> escreveu:

> Hi, all.
> ----------------
>   $ doas alsactl restore
> alsa-lib parser.c:2796:(load_toplevel_config) Unable to find the
> top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
> alsa-lib main.c:1554:(snd_use_case_mgr_open) error: failed to import
> hw:0 use case configuration -2
> alsa-lib parser.c:2796:(load_toplevel_config) Unable to find the
> top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
> alsa-lib main.c:1554:(snd_use_case_mgr_open) error: failed to import
> hw:1 use case configuration -2
>
> /home/luis
>   $ doas alsactl restore 2>/dev/null
>
> /home/luis
>   $ cat /etc/s6/sv/alsa/up
> #!/bin/execlineb -P
> if -t { test -e /var/lib/alsa/asound.state }
> fdmove -c 2 1
> exec alsactl restore
> ----------------
>
> ==> fdmove -c 2 1 dont work.
>
> What am I doing wrong? Any ideas? Thanks!
> Luis.

Re[2]: Silent or move to /dev/null alsactl restore out

[Laurent Bercot]

>i feel like this might possibly be a reason why a number of people assume that _all_ s6-ecosystem scripts have to be execline scripts.

  I don't think it is the case, no. The myth started well before s6-rc
was a thing. From the first days of s6, people assumed that, despite
the documentation explicitly saying the opposite; this has nothing to
do with execline's use in s6-rc.


>However, while it's true that in both s6 and s6-rc, use of execline is not _ultimately_ required, in the s6-rc `up` context, one _does_ have to at least use execline to call the preferred interpreter with the relevant script.

  The point of hardcoding execline here is that I need a middle ground
between "force up/down to be a path to an external script", which is
not flexible wrt e.g. existing sysvinit/openrc scripts you way want to
call with "start" and "stop" arguments, and "make up/down full
scripts/executable files", which requires embedding scripts/executables
in the compiled db, which, no.

  And that's *exactly* what execlineb is for.
  The idea is for people to write
     echo "/path/to/script start" > $oneshot/up
without wondering too much about it, and *without* needing to get lost
in the details of execline syntax. But obviously, I suck at predicting
user behaviour, and people always end up wanting to be too smart and
tying their brains in knots about incredibly simple stuff, so, whatever.

--
  Laurent

Re[2]: Silent or move to /dev/null alsactl restore out

[Laurent Bercot]

>`fdmove -c 2 1` is equivalent to shell `2>&1`. You're looking for `redirfd
>-w 2 /dev/null`.

  ... and *now* I understand what Luis wanted. Now that you're laying
it out explicitly, it was simple, and I feel dumb. Sorry.

--
  Laurent

Re: Silent or move to /dev/null alsactl restore out

[lumaro.disroot.org via supervision]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

El 2024-11-30 12:46, Laurent Bercot escribió:

>> `fdmove -c 2 1` is equivalent to shell `2>&1`. You're looking for 
>> `redirfd
>> -w 2 /dev/null`.
> 
> ... and *now* I understand what Luis wanted. Now that you're laying
> it out explicitly, it was simple, and I feel dumb. Sorry.
> 
> --
> Laurent

It really is an incredible list, sorry for my bad exposure.

1) The problem => https://ibb.co/bvx3Zrm

2) Solved => https://ibb.co/SyF1fwN

3)Clean scripts*, very nice!!
---------------
  $ cat /etc/s6/sv/alsa/up
if -t { test -e /var/lib/alsa/asound.state }
redirfd -w 2 /dev/null
alsactl restore

  $ cat /etc/s6/sv/alsa/down
alsactl store
---------------
Thank you all again!! Works fine now !!!

I'm learning as fast as I can, I don't like to ask too many questions, 
but  this system is a bit hard to learn, a pleasure to have you there.
Luis.

Re: Silent or move to /dev/null alsactl restore out

[Hoël Bézier]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

Am Sa, Nov 30, 2024 am 10:19:11 +0000 schrieb Laurent Bercot:
> > $ cat /etc/s6/sv/alsa/up
> > #!/bin/execlineb -P
> > if -t { test -e /var/lib/alsa/asound.state }
> > fdmove -c 2 1
> > exec alsactl restore
>
> [snip]
>  - Your up script is behaving differently depending on whether the
>result of the test is true or false. The "alsactl restore" command
>may or may not be called, depending on an external property (whether
>the asound.state file exists or not). This means that your machine
>state after boot is not guaranteed; this is generally a bad idea.

Sure, but what if the “alsactl restore” command depends on 
/var/lib/alsa/asound.state existing to run properly? Although this adds a race 
condition to the script, it seems better to me than using “foreground { … }” 
because one may not want to ignore all errors that may be raised by the 
command.

Hoël

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Silent or move to /dev/null alsactl restore out

[lumaro.disroot.org via supervision]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

El 2024-11-30 12:59, Hoël Bézier escribió:

> Am Sa, Nov 30, 2024 am 10:19:11 +0000 schrieb Laurent Bercot: $ cat 
> /etc/s6/sv/alsa/up
> #!/bin/execlineb -P
> if -t { test -e /var/lib/alsa/asound.state }
> fdmove -c 2 1
> exec alsactl restore
> [snip]
> - Your up script is behaving differently depending on whether the
> result of the test is true or false. The "alsactl restore" command
> may or may not be called, depending on an external property (whether
> the asound.state file exists or not). This means that your machine
> state after boot is not guaranteed; this is generally a bad idea.

Sure, but what if the "alsactl restore" command depends on 
/var/lib/alsa/asound.state existing to run properly? Although this adds 
a race condition to the script, it seems better to me than using 
"foreground { … }" because one may not want to ignore all errors that 
may be raised by the command.

Hoël

Totally agree, in this case it is more convenient "foreground" ... 
thanks !! Luis.

Re: Silent or move to /dev/null alsactl restore out

[Alexis]

"Laurent Bercot" <ska-supervision@skarnet.org> writes:

>  I don't think it is the case, no. The myth started well before 
>  s6-rc
> was a thing. From the first days of s6, people assumed that, 
> despite
> the documentation explicitly saying the opposite; this has 
> nothing to
> do with execline's use in s6-rc.

Ah okay, fair enough. Perhaps we just need those writing 
guides/tutorials to emphasise that, when presenting examples of 
execline-based service scripts, that such scripts don't _need_ to 
be execline based. Because although these guides/tutorials might 
not explicitly say "you need to learn execline", the fact that 
people don't state up-front that execline is _not_ compulsory 
might lead people to assume that it _is_.

In the case of documentation i'm putting together, i'm making an 
explicit choice to have a shebang line with dash, because i don't 
want people to feel they have to grok execline before they can use 
s6 or s6-rc.

At any rate, i can only imagine your frustration at the longevity 
of this 'furphy', to use an Australianism:

  https://en.wiktionary.org/wiki/furphy#Noun

>  The point of hardcoding execline here is that I need a middle 
>  ground
> between "force up/down to be a path to an external script", 
> which is
> not flexible wrt e.g. existing sysvinit/openrc scripts you way 
> want to
> call with "start" and "stop" arguments, and "make up/down full
> scripts/executable files", which requires embedding 
> scripts/executables
> in the compiled db, which, no.
>
>  And that's *exactly* what execlineb is for.
>  The idea is for people to write
>     echo "/path/to/script start" > $oneshot/up
> without wondering too much about it, and *without* needing to 
> get lost
> in the details of execline syntax. But obviously, I suck at 
> predicting
> user behaviour, and people always end up wanting to be too smart 
> and
> tying their brains in knots about incredibly simple stuff, so, 
> whatever.

Heh. Well, i certainly wasn't trying to suggest that you'd made a 
_bad_ or _problematic_ design choice! Just wondering if the design 
choice had contributed to the "you must use execline" thing. But 
if, as you say, this thing has long preceded s6-rc, then indeed, 
the workings of s6-rc can't be a factor.


Alexis.