why not use a systemd timer and call only /home/jhonatan/Documentos/mute-on-idle-jcc2 command ???
ps: test before alone script mute-on-idle-jcc2 - mute-on-idle-jcc2 command ? parameter is “command” ???
Every half second isn’t very practicable for a timer.
But I think OP need to rethink the approach. It looks like watch can’t be used in a systemd service. It requires a terminal. (A workaround might be using screen or temux)
Okay, I’m going to tell you the whole story.
there is a persistent “shhhhhh” in my headphones, I already checked with:
watch pacmd list-sinks
and pulseaudio works fine.
Here is the link to my publication in the sound section:
So I created my own script to automate the silence, I have no programming idea, I never wrote a script or something like that, after two days of research, trial and error I have this:
I’m going to call the main engine script:
#!/bin/bash
state=$(pacmd list-sinks | grep RUNNING | grep -o RUNNING)
if [[ $state == *"RUNNING"* ]];then
pactl set-sink-mute 0 0
else
pactl set-sink-mute 0 1
fi
I call the second script the power button:
#!/bin/bash
watch -n0,5 /home/jhonatan/Documentos/mute-on-idle-jcc2
and finally the service:
[Unit]
Description=Mute on idle
[Service]
Type=simple
User=jhonatan
ExecStart=/home/jhonatan/Documentos/call-mute
[Install]
WantedBy=multi-user.target
I would like the service to update the engine command every 0.5 seconds or 1 second if it has errors, but I don’t know how to do it.
It seemed like a reasonable time as I was using it, 1 second seemed slow, I already tried it.
So basically, you want a script that starts a script every half a second.
Could be done in one script, but doesn’t matter. Do not use watch , use a infinite loop. It can be a while or even a for loop. At a sleep command to pause for a specific time.
for example
#!/bin/bash
while [ true ]
do
/home/jhonatan/Documentos/mute-on-idle-jcc2
sleep 0.5
done
Of course you could put the content of /home/jhonatan/Documentos/mute-on-idle-jcc2 into the while loop. Then start it with the systemd service.
I quite like the result, I just want to solve a problem.
How do I hide the window of the terminal started by the script?
if we close it manually the process is dead.
So is there a way to hide the window and keep the process alive?
Did you used the loop?
You can’t really hide it, but with the loop the systemd service should work.
Yes, I used it, and it goes very well, your script gave a better direction to my construction.
well, I think we could close the issue, service is working and the scripts work as expected.
I am going to mark the answer that made the service work as a solution.
Thank you very much for your time to:
@xabbu @papajoke @Mirdarthos
Just make sure you test a reboot. It might not work as expect. But there is a fix for that.
ok, so as not to look silly XD make sure to run:
systemctl daemon-reload
systemctl start mute-on-idle.service
reboot
and everything looks and sounds normal.
If the solution is simple, you could put it in case another person needs it.
and a question before I go, what is the correct way to add more users in this section:
User=jhonatan
You only need to run it after you made a change to the service file. Not every time you want to start the service.
This command starts the service, but does not make sure it starts automatically after reboot. If you not used the enable command, the service is not running after reboot. If you want to use it after reboot, you need to enable it once.
You can’t. A systemd system service can only run for one user.
Maybe it would be better to use a systemd user service. This also would make sure it starts only after you locked in. I fear the systemd system service will fail, because it start way to early, if you enable it.
1 Like
Thank you very much for the recommendation, but now I am experimenting with these two files:
[Desktop Entry]
Version=1.0
Type=Application
Name=auto-mute
Comment=una vez lanzado el canal de altavoz y auriculares se silencia por desuso
Exec=./call-mute
Icon=kmixdocked_error
Path=/home/jhonatan/Documentos/ejecutable-comando
Terminal=false
StartupNotify=true
and this script call-mute:
#!/bin/bash
OLDEST_PID=$(pgrep -o 'call-mute')
test $OLDEST_PID && pgrep 'call-mute' | grep -vw $OLDEST_PID | xargs -r kill
while [ true ]
do
./mute-on-idle
sleep 0.5
done
The use of the service, right now I have it as plan B, because I cannot close the terminal window that opens when I log in.
But at least I know it works and that I wouldn’t hesitate to use it if I needed it or if it offered more advantages over my plan A.
Ok, I have to give you updated information, the terminal window was not opened by the service, it was done by another application that I configured related to this same issue, then I proceeded to undo everything that could cause confusion, re-enable the service, restart, and the derminal window did not appear again, the process started correctly because I could see it running in the task manager, but I was surprised that it consumes up to 5 GB of ram memory, crazy.
I am going to make small adjustments to finalize the small project and if there is something of importance to communicate, I will.
the consumption of the 5 GB in ram was because I wanted to run:
In the same script, eliminate the lines that caused this consumption and everything is in order, nothing strange in sight.
the final script would be just this:
#!/bin/bash
while [ true ]
do
/home/jhonatan/Documentos/ejecutable-comando/mute-on-idle
sleep 1
done
1 Like
You maybe want to put the content of /home/jhonatan/Documentos/ejecutable-comando/mute-on-idle in your final script.
There is no good reason to start a script that then starts another scrip, if they are relatively simple.
Also putting scripts in your Document folder is maybe not the best place in the long run. Some think a better place for a final script or program might be /home/jhonatan/.local/bin or if everybody one the system should be able to start the script /usr/local/bin .
in fact a few minutes ago, I ran into a small bug when testing from terminal, I had to make the change you mention. XD
I had not thought about it until now, it sounds practical and safe as it is a hidden folder.
I would also like to communicate that I think I already have something quite stable, I will test it thoroughly before I publish it so that others can also benefit from my little struggle XD.
sorry to say that systemd-service is not part of the final result.
This is largely due to the fact that my objective is that this can be replicated by any user who has only been using Linux for a few days, waiting for solutions of the graphic type, copy and paste, avoiding complicated commands and the use of super user as much as possible.
Although for me it was more than copy and paste, it was a bit frustrating at first but seeing the result was worth it.
I will publish the tutorial in the “sound” sector, I think it would be more coherent like that, and I will leave a link to this same thread in case someone wants to venture into systemd XD.
objectives achieved:
-a script that watches the suspension of pulseaudio “ready”
-a script that updates the vigilant every X time “ready”
-a script that avoids a clone of the process, to avoid consumption of ram and cpu incesesary “ready”
-that it executes itself when starting the section or when the system is rebooted “ready”
The problem with the “graphic” solution is that you need to describe in detail what a user needs to do. If you use pictures is only works for XFCE or Gnome or KDE or some other DE. Since the UI changes a lot, it is very fast outdate. Plus you need to trust a user it will do the correct things.
A systemd user service solution, requires 2 files to be downloaded and 4 commands to set it up. The commands can be copy and pasted in the terminal. It does not get any easier. ( 2 commands to copy the script and the systemd user service file to the correct place and two commands to reload the systemd daemon and enable the service).
In Linux the terminal is a big part. A user that does not want to get in touch with it, is usually very fast back to a different OS.
@xabbu I had not thought about the other graphic environments, and you are right, it would be unintuitive for them, in addition to the possible obsolescence of my method.
After a few minutes thinking I decided to make it work within systemd-service, anyway I think it will be one more step after the whole journey.
I already have disabled everything that had been working until now, and I file it in a corner.
let’s go back to systemd
I currently have this in/etc/systemd/system/mute-on-idle.service
[Unit]
Description="Mute on idle"
[Service]
Type=simple
User=jhonatan
ExecStart=/home/jhonatan/.local/bin/call-to-mute
[Install]
WantedBy=multi-user.target
inside the directory /home/jhonatan/.local/bin/call-to-mute this:
#!/bin/bash
while [ true ]
do
/home/jhonatan/.local/bin/mute-on-idle
sleep 0.5
done
inside the directory /home/jhonatan/.local/bin/mute-on-idle this:
#!/bin/bash
state=$(pacmd list-sinks | grep -o RUNNING)
if [[ $state == *"RUNNING"* ]];then
pactl set-sink-mute 0 0
else
pactl set-sink-mute 0 1
fi
-mute-on-idle.service “it works”
-call-to-mute “it works”
-mute-on-idle “it does not work”
I do not understand why this happens, I already did tests by terminal and it should work without problems
output of: systemctl status mute-on-idle
● mute-on-idle.service - “Mute on idle”
Loaded: loaded (/etc/systemd/system/mute-on-idle.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-02-17 22:07:55 CET; 21min ago
Main PID: 650 (call-to-mute)
Tasks: 2 (limit: 9416)
Memory: 4.0M
CGroup: /system.slice/mute-on-idle.service
├─ 650 /bin/bash /home/jhonatan/.local/bin/call-to-mute
└─17201 sleep 0.5
feb 17 22:29:19 corporacion-latitudee5540 call-to-mute[17184]: El demonio PulseAudio no está ejecutándose, o no se está ejecutando com>
feb 17 22:29:19 corporacion-latitudee5540 call-to-mute[17186]: Error en la conexión: Conexión negada
feb 17 22:29:19 corporacion-latitudee5540 call-to-mute[17186]: pa_context_connect() falló: Conexión negada
feb 17 22:29:20 corporacion-latitudee5540 call-to-mute[17190]: El demonio PulseAudio no está ejecutándose, o no se está ejecutando com>
feb 17 22:29:20 corporacion-latitudee5540 call-to-mute[17192]: Error en la conexión: Conexión negada
feb 17 22:29:20 corporacion-latitudee5540 call-to-mute[17192]: pa_context_connect() falló: Conexión negada
feb 17 22:29:21 corporacion-latitudee5540 call-to-mute[17198]: El demonio PulseAudio no está ejecutándose, o no se está ejecutando com>
feb 17 22:29:21 corporacion-latitudee5540 call-to-mute[17200]: Error en la conexión: Conexión negada
feb 17 22:29:21 corporacion-latitudee5540 call-to-mute[17200]: pa_context_connect() falló: Conexión negada
feb 17 22:29:21 corporacion-latitudee5540 call-to-mute[17204]: El demonio PulseAudio no está ejecutándose, o no se está ejecutando com
I don’t know if pulseaudio has something to do with the malfunction
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.