dmesg-speak: How to get the kernel to speak as early as possible?

quequotion · 2015-02-11 16:52:32

EDIT: Repurposed:
Getting the systemd service running has been resolved, but spd-say fails to execute because it needs an audio output. How can we get an audio output before users log in and can we keep it going after they do?

I haven't been able to make a successful systemd service from this script.

The script itself works (in terminal and xdg autostart), but systemd doesn't run anything after the first pipe (neither sed nor spd-say execute).

Here's my service:

[Unit]
Description=Speak kernel and userspace messages
 
[Service]
Type=simple
ExecStart=/usr/local/sbin/dmesg-speak
 
[Install]
WantedBy=multi-user.target

Systemd says the script starts successfully, but only dmesg is started; it's output is not piped through sed or spd-say.

I've also tried Type=forking without much success.

Is there something I can do other than switching to sysv-init?

Do I need IgnoreSIGPIPE=false?

Last edited by quequotion (2015-08-20 15:51:31)

th3voic3 · 2015-02-13 08:00:54

Try

ExecStart=/usr/bin/bash /usr/local/sbin/dmesg-speak

quequotion · 2015-02-17 05:08:39

th3voic3 wrote:

Try

ExecStart=/usr/bin/bash /usr/local/sbin/dmesg-speak

Close, but not quite

Wih this, systemd executes demsg and sed, but not spd-say.

I thought it might be that two pipes are too many, so I tried without sed, but it still failed.

I thought it might be the hyphen in spd-say, so I tried a variety of quotation and escape methods, but it still failed.

Finally, I wrote a oneshot service that does nothing but:

ExecStart=/usr/bin/spd-say hi

This also fails.

Systemd refuses to execute spd-say, apparently skipping over it as though it weren't even there.

firecat53 · 2015-02-17 05:21:09

My guess is that it has something to do with the environment and enabling systemd to attach to whatever sound system you are using (pulseaudio?)

Scott

quequotion · 2015-02-17 05:38:24

firecat53 wrote:

My guess is that it has something to do with the environment and enabling systemd to attach to whatever sound system you are using

That could be it; if spd-say is crashing because it isn't permitted to use audio (yes, pulseaudio but the alsa backend should work just as well).

How to debug this? Neither spd-say nor systemctl ouput anything useful. "sudo spd-say hi" works; it doesn't appear to be a problem with SUID. It could be a problem with groups.

Do I need to add something to the "audio" group?

firecat53 · 2015-02-17 06:38:18

If I create a systemd service file in ~/.config/systemd/user/test.service:

[Unit]
Description=play file

[Service]
Type=forking
ExecStart=/usr/bin/mpv <path to music file>

it starts and plays the song/video if I start it using

systemctl daemon-reload
systemctl --user start test.service

because the pulseaudio session exists for my user. Your unit is running as root, which has no associated pulseaudio session. So you can either run your service as your user, or attempt to attach the root service file to your user session (or make pulseaudio run for the root user....good luck )

Scott

quequotion · 2015-02-17 16:28:29

firecat53 wrote:

the pulseaudio session exists for my user. Your unit is running as root, which has no associated pulseaudio session. So you can either run your service as your user, or attempt to attach the root service file to your user session (or make pulseaudio run for the root user....good luck )

Thank you!

Hrm.. looks like the only way to share access to pulseaudio between users and root is to run it as a system-wide instance, which I have only ever read about being a bad idea.

The service does work in user mode, but this isn't much different from an xdg autostart; I was hoping there would be a way to get dmesg speaking earlier than user login.

Maybe I can find a way to do it with just espeak and alsa.

ccoffey · 2015-02-25 14:54:04

If a pulseaudio session exists at all, you can play to it if you have DISPLAY variable set.

If you don't have X running, you could run pulseaudio and dbus via XVFB.
Setting DISPLAY as root would then allow you play audio.

I use it this way via my pi.

fsckd · 2015-02-25 19:37:15

@quequotion: The linked script appears to lack a hashbang. No hashbang = arbitrary interpretor.

(The spd-say stuff seems to be already addressed. I'll leave that to people who understand it better than I.)

quequotion · 2015-02-26 02:08:45

fsckd wrote:

The linked script appears to lack a hashbang. No hashbang = arbitrary interpretor.

Yeah, that should probably be there. Since last post I've employed /usr/bin/bash in the service and added a hasbang, but sdp-say still does not run as a systemd service.

I didn't test either option individually; the key seems to be finding an audio output accessible before user login. I am not certain:

ccoffey wrote:

If a pulseaudio session exists at all

I am curious to try this:

ccoffey wrote:

run pulseaudio and dbus via XVFB.
Setting DISPLAY as root would then allow you play audio.

Still, it seems to me that ALSA would be available at some stage during boot, as is speech-dispatcher (for working with speakup!). If espeak were configured to play audio for root to ALSA, there would be a sound outlet for it (espeak can be used in pipeline mode without speech-dispatcher if need be), and pulseaudio would be probably be OK with that whenever it got around to starting (audio passed through alsa gets piped through, regardless of its source right?).

I have tried the script with espeak instead of spd-say without success.

Last edited by quequotion (2015-02-26 03:06:24)

Jristz · 2015-02-26 02:25:33

Why not ask into systemd or pulseaudio mailistings?
Lennart Poetering's systemd and pulseaudio ceator, maybe Lennart could help hinting why is not working or how correctly do the thing.

ackalker · 2015-03-16 16:46:38

@quequotion
If you don't mind not hearing your script talk when no-one is logged in (or if there's always a user logged in), then please have a look at http://superuser.com/a/734756/371479, which shows how to run both dmesg (with recent kernel and util-linux, which Arch Linux has) and journalctl in 'follow' mode.
Don't let the '#'s fool you, neither command needs to be run as root.

This means that you could run your script as a systemd user service, bypassing the problem of making spd-say running as root talk to pulseaudio running in a user session.

Last edited by ackalker (2015-03-16 16:53:14)

quequotion · 2015-08-19 19:46:21

ackalker wrote:

If you don't mind not hearing your script talk when no-one is logged in

I'm looking for a way to get the kernel to start speaking before any user login, the point being to get output as early as possible--including boot messages if possible.

I don't really have any intention to use pulseaudio for this as I am almost certain it is not possible (aside from the XVFB method, which I have not yet attempted).

I could ask Lennart for ideas as Jristz suggests, but personal experience leads me to think my time would better be spent waiting for him to decide to incorporate pulseaudio into systemd on his own.

Arch Linux

#1 2015-02-11 16:52:32

dmesg-speak: How to get the kernel to speak as early as possible?

#2 2015-02-13 08:00:54

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#3 2015-02-17 05:08:39

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#4 2015-02-17 05:21:09

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#5 2015-02-17 05:38:24

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#6 2015-02-17 06:38:18

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#7 2015-02-17 16:28:29

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#8 2015-02-25 14:54:04

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#9 2015-02-25 19:37:15

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#10 2015-02-26 02:08:45

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#11 2015-02-26 02:25:33

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#12 2015-03-16 16:46:38

Re: dmesg-speak: How to get the kernel to speak as early as possible?

#13 2015-08-19 19:46:21

Re: dmesg-speak: How to get the kernel to speak as early as possible?

Board footer