I want to be able to send a SIGHUP signal to a Prometheus process from a CI tool that runs with a different user than Prometheus. Let's say CI uses gitlab-runner user and Prometheus uses prometheus user. I thought that I can achieve sending a SIGHUP signal to the Prometheus process by following steps:

  1. Creating a simple shell script that executes kill command:
$ cat `which promhup`
kill -HUP $(pgrep prometheus)
  1. Change the ownership of this script and set the setuid bit for this file:
chown prometheus promhup
chmod +x promhup
chmod u+s promhup

Then, I expected that if I simply run promhup, it can send the desired signal to the Prometheus process. However, I get the following error:

/usr/bin/promhup: line 1: kill: (602) - Operation not permitted

The permissions now look like this:

$ ls -l `which promhup`
-rwsr-xr-x 1 prometheus root 51 Jan 27 19:36 /usr/bin/promhup

What have I done wrong? How can I accomplish this without giving a sudo access to my CI user?


Linux ignores setuid bit on scripts/interpreted executables (the ones that start with #!) for the reasons of security.

As a kind of hacky solution you can try to compile a simple binary out of your script using https://github.com/neurobin/shc and setuid it:

sudo add-apt-repository ppa:neurobin/ppa
sudo apt-get install shc

shc -f my_promhup_script -o promhup
sudo mv promhup /usr/bin/

Although I'd rather go for the sudo option - that's what it was designed for.


For the sudo option, you can add something like this to your sudoers:

gitlab-runner ALL = (ALL) ALL
gitlab-runner ALL = (root) NOPASSWD: /usr/bin/promhup

this will make your sudo not ask password only for your script, while asking it for the others

source: https://unix.stackexchange.com/questions/18830/how-to-run-a-specific-program-as-root-without-a-password-prompt

  • Thanks! About sudo, I thought that using sudo approach would introduce additional security risks, since I need to give it passwordless sudo access because of the nature of its execution. That's why I think it can be risky in this case. I will try the shc approach and will be back here!
    – Ali Tou
    Jan 27 '21 at 16:43
  • It seems that shc can't work either. I suppose that $(pgrep prometheus) is tricky here. The output that I get is promhup: ���D|?r����A�V�C3��^Dk with status code 1.
    – Ali Tou
    Jan 27 '21 at 16:49
  • 1
    @Ali Tou you can make sudo not ask for password for specific binaries or scripts. Check this out: unix.stackexchange.com/questions/18830/…. Added it to the answer.
    – O.W.Grant
    Jan 27 '21 at 16:52
  • Hi. Just came here to firstly thank you for the time you spent for my question. The first paragraph you mentioned inspired me to write an equivalent program in C, which worked. I'm gonna add it as a separate answer for the record.
    – Ali Tou
    Aug 21 '21 at 11:44

The first paragraph of @O.W.Grant's answer gave a great point in solving the problem:

Linux ignores setuid bit on scripts/interpreted executables (the ones that start with #!) for the reasons of security.

It inspired me to write an equivalent program in C, which worked:

#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
  FILE *fp;
  char pid[10];

  fp = popen("/usr/bin/pgrep prometheus", "r");
  if (fp == NULL)

  fgets(pid, sizeof(pid), fp);

  char* ptr = pid;
  while(ptr) {
    if(*ptr == '\n') {
      *ptr = '\0';


  char* args[] = {"/usr/bin/kill", "-HUP", pid, NULL};
  execvp(args[0], args);

  return 0;

The usage would be:

gcc promhup.c -o promhup
chmod +x promhup
chown prometheus promhup
chmod u+s promhup
sudo mv promhup /usr/bin

Then running a simple promhup command would send a SIGHUP signal to the Prometheus process.

  • @user1686 Ouch, you're right. My thoughts were biased on using shell commands and I didn't even think about the system calls world.
    – Ali Tou
    Aug 21 '21 at 11:57

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.