2

I have an executable compiled from my code. I am trying to run this executable when I insert a serial device into my Raspberry Pi Zero W using udev. However, for some reason the executable will not run, I have looked with top and there is no sign of the process.

Here my udev rules file in /etc/udev/rules.d/10-serial-usb.rules:

ACTION=="add", SUBSYSTEM=="usb", KERNEL=="1-1.3", ATTR{idProduct}=="7523", ATTR{idVendor}=="1a86", RUN="/bin/bash /home/blackbox/blackbox-cpp/run.sh"

And here is the bash script in /home/blackbox/blackbox-cpp/run.sh:

#!/bin/bash

/home/blackbox/blackbox-cpp/bin/blackbox &

The bash script definitely runs because I have used commands like mkdir and touch from the script to test that it is actually being run, and they each work correctly. So why is my executable different?

Let me clarify that by not working, I mean that the executable does not appear to be running with top.

Improve this question
10
  • Does it work better if you run the executable directly from the udev rule? Unless there is more to your script you are not showing us, that is just adding a pointless layer of complexity. What happens if you just have RUN="/home/blackbox/blackbox-cpp/bin/blackbox" in the udev rule? Also, top only shows the top processes by whatever you are sorting with, better to test with pgrep blackbox or ps aux | grep blackbox. Commented Sep 6, 2022 at 10:11
  • Is the executable you're running interacting with a graphical user interface (opening windows etc.)? Commented Sep 6, 2022 at 10:23
  • @Kusalananda No, it all runs through a CLI. Commented Sep 6, 2022 at 10:45
  • @terdon Yeah, I've tried before running it directly from the udev rule. All with the same outcome. The process either isn't running at all, or its runs very briefly before terminating. Commented Sep 6, 2022 at 10:50
  • 1
    OK, so it's erroring out. Change your script so that it runs /home/blackbox/blackbox-cpp/bin/blackbox 2>/tmp/blackbox.log 1>&2 and then check the file /tmp/blackbox.log for errors. Commented Sep 6, 2022 at 10:56

3 Answers 3

Reset to default
1

So to answer my own question, turns out there was an error when reading my configuration file. I am using a JSON file to read in a set of configurations and because udev runs items from the root directory, it could not find this file.

So all I had to change in my bash script to get around this was inserting a change directory to the path of the configuration file.

#!/bin/bash

cd /home/guy/blackbox-cpp/
bin/blackbox

Thanks to @terdon who helped me to discover the error.

Improve this answer
1
  • You probably want ./bin/blackbox there, even if you are on a system that adds . to the PATH, it is more portable and cleaner to make it explicit. Commented Sep 6, 2022 at 11:18
0

top displays the top CPU users (default). The list is not the list of all processes running. It is possible that your application uses very little CPU and therefore, it might not be in the top.

To be sure that the process does not run, try

ps -ef | grep blackbox

You may also change the script to:

#!/bin/bash
echo $$ > /tmp/blackbox.sh.pid
/home/blackbox/blackbox-cpp/bin/blackbox

and do a pstree -an xxxxx where xxxxx is the PID in your PID file.

Improve this answer
4
  • Okay thanks for your response. I put that in my bash script and I got a PID output in the /tmp/blackbox.sh.pid file. However, when I used pstree, there was no further output. So that suggests to me that the process starts but immediately closes? Commented Sep 6, 2022 at 10:45
  • I missed the & add the end of the command. Remove that &. Commented Sep 6, 2022 at 10:51
  • Removed the &, still no output. Commented Sep 6, 2022 at 10:54
  • Then your /home/blackbox/blackbox-cpp/bin/blackbox exists directly. Without knowing anything about your blackbox, it is very hard to make any suggestions. If there are any logging or debug options,enable them all. They might give some clue on what's going wrong. Also, redirect the STDOUT and STDERR of yoour cpp-version to some files. Commented Sep 6, 2022 at 10:59
0

See man 7 udev:

Starting daemons or other long-running processes is not allowed; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.

If you want to run background process in udev rule create systemd service and start it with systemctl start <your_service>.

Improve this answer
3
  • Yes I am aware of this, hence why I am running from a bash script. Will that not get around this? Commented Sep 6, 2022 at 11:09
  • @GuyChamberlain-Webber added to answer. Commented Sep 6, 2022 at 11:10
  • @GuyChamberlain-Webber No. Udev run programs in separate namespace and terminate all child processes spawned by program. Commented Sep 6, 2022 at 11:13

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.