When I boot my Raspberry Pi3 (4.14.34-v7+), I find the following error in the dmesg and other logs, after boot up. However, I am not currently using triggerhappy, so could probably disable that service. But in case I want to use in the future, I would like to know what is causing that error.

systemd-udevd[157]: Process '/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev' failed with exit code 1.

There are two entries in the systemd services:

systemctl status triggerhappy.service
systemctl status triggerhappy.socket

And the code trying to be executed seem to come from:

Why does this fail during boot?
(It seem to run later though...)

2 Answers 2


Why: This error is being caused by a combination of things:

1) The command th-cmd --socket /var/run/thd.socket --passfd --udev produces a segfault. This seems to be because triggerhappy hasn't been patched to address a number of issues reported over the last 4 years...

2) Unfortunately, the error will still appear in syslog even if you disable triggerhappy Eg:

$ sudo systemctl disable triggerhappy.service
$ sudo systemctl disable triggerhappy.socket

This is because disabling triggerhappy doesn't remove the udev rules here: /lib/udev/rules.d/60-triggerhappy.rules.

Solution (If you're not using triggerhappy anyway - like on a headless system):

$ sudo apt-get remove triggerhappy
  • Are you sure that a segfault causes exit code 1?
    – Scott
    May 28, 2019 at 16:17
  • 1
    The short answer is: No, I'm not sure if the process th-cmd segfaults after being launched during boot up. Perhaps the process that launches th-cmd (systemd-udevd, I believe) reports exit code 1 after th-cmd is unsuccessful at doing whatever it's meant to do. "th-cmd --socket /var/run/thd.socket --passfd --udev" segfaults when issued from the command line after boot. May 28, 2019 at 17:45
  • Thanks! I had completely forgotten about this issue. Accepted
    – not2qubit
    Mar 30, 2020 at 19:42

As pointed out by @Caleb there unfortunately seems to be a long standing bug in the triggerhappy service. But the udev rule can be useful if you want the triggerhappy happy daemon to take account of events triggered by new event sources - which can come from devices that are connected to the machine during or after boot. To work around this bug you can replace the RUN line in the 60-triggerhappy.rules file with the following:

        RUN+="/bin/systemctl restart triggerhappy"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.