Pgrep doesn't work in Wayland session

Hi Guys,

I have the following script that records audio output:


if pgrep parec
	# Stop recording audio
	pkill parec
	# Output device (the default one)

	# 5-character random string
	rand=$(cat /dev/urandom | tr -dc 'A-Z0-9' | fold -w 7 | head -n 1)

	# Construct filename
	filename="$(xdg-user-dir DOWNLOAD)/out_${rand}.mp3"

	# Record audio to the file
	parec -d $targetSink --volume=65536 | lame -r -V7 - $filename

	# Copy the file to the clipboard
	echo "file://${filename}"|xclip -i -sel c -t text/uri-list

The idea is that when first launched it starts recording audio, and then on second launch it kills parec process and stops recording. When launched from Konsole it works correctly, but when I assign a shortcut to it (e.g. Super + A) and then try call, it seems like pgrep either doesn’t work or it is not able to find the process.

The issue is reproducible on KDE Plasma 5.27 (Wayland). When the script is launched several times, the if always evaluates to false (system cannot find the parec process), so it creates a new file each time. On X11 session the script works fine. It also behaves correctly on Xfce.

Do you know what could be the root-cause and how it could be fixed?


Not an answer but does the xclip run under wayland?

Yes, it worked both on KDE Plasma and GNOME. According to what I know there are no real Wayland alternatives that could copy audio files to clipboard:( But at least xclip is compatible.

Yes, the issue is using xclip on Wayland. That doesn’t work since it’s X11 only. Try using wl-copy instead.

Unfortunately, it doesn’t even reach the xclip. The pgrep in if statement doesn’t work correctly in this situation for some reason. BTW, do you know a proper way how to copy files into clipboard from bash on Wayland? It seems like wl-copy doesn’t support this scenario currently.

pgrep works fine for me on Wayland FWIW.

$ pgrep firefox

Why do you need to copy the whole file into the clipboard? Can you rework the script so that simply copying the filename is enough?

pgrep works fine if called from bash manually, or if the script is launched from terminal. The xclip command in the script successfully copies file to clipboard too. The problem arises when the script is called not from a terminal (Konsole in this case), but by assigning a keyboard shortcut to it and using this shortcut.

I believe this xclip command uses a standard approach for copying files to clipboard. Perhaps it stores not the entire file, but a reference to it. The most important thing is that when script is called second time, the recording of output audio under normal circumstances is stopped by killing parec process, then the line with xclip is reached and the file is copied to clipboard. Pressing Ctrl+V in Anki or any other app allows to paste the file.

@JayXT I believe you just need to debug it: apparently running it through a shortcut (without being attached to a terminal?) makes it fail in some unexpected way.

In your case I would try to redirect any error message that might be generated to some temporary file and see what’s going on.

I would probably create a wrapper script with the following contents


/path/to/ &> /tmp/log_file

and then assign this wrapper script to the shortcut and examine the /tmp/log_file.

Hope it helps :slight_smile:

PS: Extra hint: maybe add absolute paths to each command?


Got it, thanks for the tip! I’ll give it a try later.

@jsalatas, it seems like the log is empty. The file is created, but nothing is written to it. Perhaps, no errors are detected.

UPD: to be sure that something is logged, I’ve added the following line to the original script at the beginning: echo $(pgrep parec). However, this hasn’t change the result (empty log file).

It should have something the first time you run it. Ie the time that it is supposed to run else part.

My point is that it fails before it runs parec

From what I observe, the script runs parec step successfully. It also writes mp3 files to the intended directory. Although, when called from shortcut it starts parec on each execution, which means that pgrep parec doesn’t work (it always returns false) and thus recording never finishes. In other words, new parec processes are spun up each time the defined keyboard shortcut is used.

Anyway, the issue is not critical right now. The problem isn’t reproducible in GNOME and Xfce, so for the time being, I rely on these DEs to achieve the goal of recording audio output.

Thank you for your help!

You may want to use the env command in order to output all the environment variables and then compare the output when running in a terminal and when running through a shortcut.

I’m not sure why, but when the original script is called the following way, it worked correctly:

record_audio_output_log file (referenced in a shortcut):


/home/user/.local/bin/record_audio_output >> /home/user/Downloads/log_file

And I have no idea, what’s the difference apart from the fact that it redirects output to a log file. For some reason in this case pgrep works and on second shortcut press, the parec process is detected by pgrep, killed by pkill, which stops the recording.

But if >> /home/user/Downloads/log_file part is deleted, the problem gets reproduced again.

I have no idea! In any case you should probably check the output of the env command under different scenarios. I believe it will provide you at least a hint.

I’ve considered this option, but if I’m writing to the log, there’s no issue, if I’m not writing, there’s an issue, but no way to know the environment variables.

You would still get some hint. It makes no sense otherwise.