I want to understand a little bit better, what a background process is. The question came to live as a result of reading this line of code:

/usr/sbin/rsyslogd -niNONE &

[Source](https://github.com/Mailu/Mailu/blob/c2d85ecc3282cdbc840d14ac33da7b5f27deddb3/core/postfix/start.py#L94) The documentations says: > -i pid file > Specify an alternative pid file instead of the default > one. This option must be used if multiple instances of > rsyslogd should run on a single machine. To disable > writing a pid file, use the reserved name "NONE" (all > upper case!), so "-iNONE". > > -n Avoid auto-backgrounding. This is needed especially if > the rsyslogd is started and controlled by init(8). [Source](https://man7.org/linux/man-pages/man8/rsyslogd.8.html) The ampersand & seems to mean to request that the command is run in the background, see, for example [here](https://unix.stackexchange.com/a/86253/70683) . If my understanding is correct, pid files [are used with daemons](https://unix.stackexchange.com/a/12816/70683) , that is when a program is run in the background. So on the face value it seems that the command in question first tells the program not to run in the background with -n, then specify NONE for the pid file, to indicate it is not a daemon1, and then right after that specify & to send it into the background. I cannot make a lot of sense of that. Is the background that the process would normally enter is a different background it is sent to by using &? From all I read, it seems that the only meaning of the background is that shell is not blocked. In this respect asking the process not to auto-background and then background it does not make a lot of sense. Is there something here I'm missing? What is exactly the background? (And who is responsible for deleting the pid file, while we are at it?) --- 1 - in a docker container context, where the question arose from, the existence of the pid file can cause problems when the container is stopped and then restarted. It is not clear for me what is responsible for deleting the pid files, some sources suggest that it's [the init system, such as systemd](https://unix.stackexchange.com/a/256130) , while others [imply that it's the program responsibility](https://stackoverflow.com/a/688365/18625995) . However if a process killed with SIGKILL the program might not have an opportunity to delete it, so subsequent container re-start will fail because the pid file will already be there, but is expected not to.

i got such situation 1) there is a power failure 2) the UPS battery is drained during power failure 3) the servers in rack are shut off from power lose 4) power is restored 5) servers powering up and their os'es are booting 6) systemd is doing its work 7) and now **some software** (systemd services startup scripts) are in deep black hole as they **startup ryles on the pid's file existence and not of the check up of the PID (number) in pid file (var/run) process is still alive** refusing to startup and that makes unwanted cascade of sh..t and now my questions 1) as im not the software designer and im not able to be software keeper to make/force designer to do his creation to work "proper or as it should" 2) im not ale to constantly keep my hands on pulse to check that all services are working as it's expected to, especially after a each update **3) howto maintain such situation globally?** a) its good idea o make a script and execute it on systemd service on each boot of server (linux kernel) to verify of pid file processes existence ? in case of ps gone delete the pid file b) if so where such entry point for such service should be c) how such script should handle the systemd services especially multiple .services file location and the pid file named in those service files *with use of find or grep tools" .. as a blocking service ? it wold be a time cost solution ... d) or there is already better solution if so which one ? or some already made soft ? maybe just hook after a init (process) ? and do just rm all *.pid ? by find -name *.pid ? exec rm ? it wold be 99% of job done :D or do a systemd unit ExecStartPre= script for such each service to delete itself ? but it wold be time consuming to trace and edit service file and there is a "update" issue when sysyemd scirpt get changed by author ??? 4) or maybe is there a unique stanza to exec a PreExecScipt for each systemd service bulk/globally without interfering to the service scripts? ps. **and last question .... when I ask for solution to my real problem, you (by being the victim) you are punish me for the developers' mistakes by downvoting my.. why?** **i'm not responsible for other mistakes or bad knowledge or it's lack** ps2. **"I am not in a position to look at the performance of every piece of software I use and install every day, but there is a group such so im having similar problems with it and I want to be able to prevent it"** ps3. ok when it goes to **run** folder i know the rules on my DEBIAN and other distros like: https://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2Fvar.2Frun_to_.2Frun_and_.2Fvar.2Flock_to_.2Frun.2Flock.3F https://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2Fvar.2Frun_and_.2Fvar.2Flock https://wiki.debian.org/ReleaseGoals/RunDirectory#Why_can.27t_.2Fvar.2Frun_and_.2Fvar.2Flock_stay_under_.2Fvar.3F

it's not a simulation or theory it's REAL LIFE and it's not so colorful as you think so i ask for hel once again HOW TO COUNTERACT AGAINST ORPHANED PID FILE EXISTENCE AFTER REBOOT ON A POWER FAILURE WHEN THE PROGRAM DOESN'T HANDLE IT IN PROPER WAY

from software developer manual > Kea’s servers create PID files upon startup. These files are used by keactrl to determine whether a given server is running. If one or more servers are running when the start command is issued, the output looks similar to the following: keactrl start INFO/keactrl: kea-dhcp4 appears to be running, see: PID 10918, PID file: /usr/local/var/run/kea/kea.kea-dhcp4.pid. INFO/keactrl: kea-dhcp6 appears to be running, see: PID 10924, PID file: /usr/local/var/run/kea/kea.kea-dhcp6.pid. INFO/keactrl: kea-dhcp-ddns appears to be running, see: PID 10930, PID file: /usr/local/var/run/kea/kea.kea-dhcp-ddns.pid. INFO/keactrl: kea-ctrl-agent appears to be running, see: PID 10931, PID file: /usr/local/var/run/kea/kea.kea-ctrl-agent.pid. INFO/keactrl: kea-netconf appears to be running, see: PID 10123, PID file: /usr/local/var/run/kea/kea.kea-netconf.pid. > **During normal shutdowns, these PID files are deleted; they may, however, be left over as remnants following a system crash. It is possible, though highly unlikely, that upon system restart the PIDs they contain may actually refer to processes unrelated to Kea. This condition will cause keactrl to decide that the servers are running, when in fact they are not. In such a case the PID files listed in the keactrl output must be manually deleted.** so we ends with pids in non volatile inode -> /usr/local/var/run all best T. Best aka ceph3us

On http://www.cs.newpaltz.edu/~easwaran/Resources/commands.html the following command is listed as being meant to "Refresh the syslog process":

kill -1 cat /var/run/syslogd.pid

I have seen this command in real-life use on an embedded device but I cannot wrap my mind around why someone would use it and how it works. I understand the single parts this is made up off, but e.g. why is the cat subshell killed using a HUP signal is not something which makes sense to me.

In our application, we start some background processes. The pid of these processes is saved to a file. pids values are re-used when the maximum is reached or when the system is rebooted. How can I reliably check that the process with pid X is still the same process for which X was stored. I've read https://serverfault.com/questions/366474/whats-a-proper-way-of-checking-if-a-pid-is-running and https://stackoverflow.com/questions/3043978/how-to-check-if-a-process-id-pid-exists but these solutions never check if the process that has pid X is the still same process as the one for which the pid was stored. I need this info to reliably * check the process is still running * kill the process without risking to kill a different process that now has pid X related https://serverfault.com/questions/279178/what-is-the-range-of-a-pid-on-linux-and-solaris I will post my current solution. I'd like to know if it's a sensible approach and if there are better ways to do this.

I'm running QEMU virtual machine in -daemonize mode and then spawn an arbitrary foreground (possibly interactive) process intended to interact with the QEMU instance. In general once foreground process completes I do a cleanup of QEMU instance via pidfile: qemu-system ... -pidfile ./qemu.pid -daemonize /my/custom/interactive/process pkill -F ./qemu.pid However in some scenarios QEMU could exit independently and my foreground process continues to run. But I would like to stop it in case. So the behavior of my custom interactive process should be like: tail -f --pid=./qemu.pid /dev/null How can I do that nicely? Maybe there is some kind of timeout-like wrapper, so I could run something like: trackpid ./qemu.pid /my/custom/interactive/process

I have a bash script that calls a Python script that I want running continuously in the background. I can start the bash script, and the Python script runs, but I can't stop it using the "stop" command with the bash script. Here is the bash script:

#!/bin/bash

 case $1 in
    start)
       echo 'Running test.py'
       exec 2>&1 /opt/anaconda3/envs/my_env/bin/python /home/my_name/scripts/test.py &
       echo 'Assigning pid'
       echo $! > /home/my_name/scripts/test.pid;;
     stop)
       kill 'cat /home/my_name/scripts/test.pid';;
       
     *)
       echo "usage: "$1" {start|stop}" ;;
 esac
 exit 0

And here is the Python script:

import time
from pathlib import Path

count = 0 
while True:
    with open(Path(__file__).parent.resolve() / "test.txt", 'a') as f:
        f.write(str(count))
    count += 1
    time.sleep(1)

The Python code works fine so it's not worth discussing much. It just writes an integer to a text file every second, each time incrementing by one. Here is what I get on the command line from within the folder containing the Python and bash scripts:

$ sudo ./test.sh start
Running test.py
Assigning pid
$ sudo ./test.sh stop
./test.sh: line 10: kill: cat /home/my_name/scripts/test.pid: arguments must be process or job IDs
$ ps -aux | grep test
root      91366  0.1  0.0  26704  9320 pts/6    S    19:39   0:00 /opt/anaconda3/envs/my_env/bin/python /home/my_name/scripts/test.py
VEIC\da+  92004  0.0  0.0  14436  1012 pts/11   S+   19:41   0:00 grep --color=auto test
$ cat test.pid
91366

So you can see the pid written to the pid file test.pid matches the one shown with the command ps -aux | grep test. But when trying to use the stop command with the bash script I'm told that the contents of the pid file aren't a process or job ID. I'm eventually hoping to use this in conjunction with Monit, but need to get past this bash script difficulty before I do so. Any help would be greatly appreciated!

I often see that programs specify pid and lock files. And I'm not quite sure what they do. For example, when compiling nginx: --pid-path=/var/run/nginx.pid \ --lock-path=/var/lock/nginx.lock \ Can somebody shed some light on this one?

How can I start a program and write its output to a log file, where the log file contains the PID in its name? I tried program_a > log_$! which doesn't work since $! is the PID of the last program and `program_a' has not finished when the log file is created.

I'm working on an emailnotifier script on RaspberryPi which was written in Python. I've found a tutorial page, I've exactly copied the default code (which works fine with a simple "python emailnotifier.py") but I wanted to improve it as a startup service. The code can be found at the bottom at this page (Sorry dunno how to insert it): https://pimylifeup.com/raspberry-pi-email-notifier/ After I start the service then check the status, the following can be read: "Stopping system #DAEMON_NAME daemon:start-stop-daemon: warning: failed to kill 2270: No such process No process in pidfile '/var/run/emailnotifier.pid' found running; none killed. failed!

I need to store the pid number in a file/files. How to do it?

To use a pid file for ensuring singleton running instance of a program, I thought that when a process finishes running the program, it should remove the pid file, until I know it doesn't when reading https://stackoverflow.com/a/7453411/156458 : #!/bin/bash mkdir -p "$HOME/tmp" PIDFILE="$HOME/tmp/myprogram.pid" if [ -e "${PIDFILE}" ] && (ps -u $(whoami) -opid= | grep -P "^\s*$(cat ${PIDFILE})$" &> /dev/null); then echo "Already running." exit 99 fi /path/to/myprogram > $HOME/tmp/myprogram.log & echo $! > "${PIDFILE}" chmod 644 "${PIDFILE}" > Here's how it works: The script first checks to see if the PID file exists ("[ -e "${PIDFILE}" ]". If it does not, then it will start the program in the background, write its PID to a file ("echo $! > "${PIDFILE}""), and exit. If the PID file instead does exist, then the script will check your own processes ("ps -u $(whoami) -opid=") and see if you're running one with the same PID ("grep -P "^\s*$(cat ${PIDFILE})$""). If you're not, then it will start the program as before, overwrite the PID file with the new PID, and exit. I see no reason to modify the script Does the above script assume that no pid is recycled? Can it happen that a process finishes running the program, and its pid is reused by a new process running a different program? In such a case, the quoted script will falsely think that a process is running the program. Thanks.

Recently I developed the habit of killing processes with fuser -k -n tcp $PORT which can hardly kill the wrong process. I prefer this over fiddling with a pidfile that may or may not be still there or may or may not contain the correct pid (OK, I am a bit dramatic here :-) Yet the typical stop script I stumble over still uses a pidfile. Am I missing an important feature of the pidfile approach or a misfeature of the fuser approach. My best guess is that fuser is not available. Though judging by search engine results, bsd, debian, suse, centos, aix, solaris all seem to have it.

I have an init script that executes a jar file in the background, and I want to print the PID to a file. Using the following immediately after the execute command the file is created, but it is empty. start process & \ echo $! >/var/run/foo.pid Why might this be? Thanks

I have an application written in python which I've used many times with CentOS 6, and am now setting it up on CentOS 7. I've created a systemd service file that contains the following: # # Systemd unit file for Application # [Unit] Description=Application Daemon [Service] User=svc_app Group=svc_app Type=forking ExecStart=/usr/bin/python /apps/application/run_app.py --daemon --pidfile=/var/run/apps/application.pid ExecStop=pkill --pidfile /var/run/apps/application.pid PIDFile=/var/run/apps/application.pid [Install] WantedBy=multi-user.target If I run systemctl start application.service, the app starts. If I run systemctl stop application.service, the app stops. If I run systemctl status application.service, I get the correct status. However, I'm experiencing two log messages that are concerning, and not sure why I'm getting them. Jun 10 18:36:43 centos7-test systemd: Starting Application Daemon... Jun 10 18:36:44 centos7-test systemd: PID file /var/run/apps/application.pid not readable (yet?) after start. Jun 10 18:36:44 centos7-test systemd: Started Application Daemon. App starts, but the message application.pid not readable had me concerned. Should I be concerned about this, or can I ignore it? My application is successfully creating a pid file that contains the pid of the running instance, so I know that's working correctly. Second issue is when I run systemctl stop application.service. Jun 10 18:49:33 centos7-test systemd: Stopping Application Daemon... Jun 10 18:49:43 centos7-test systemd: Stopped Application Daemon. Jun 10 18:49:43 centos7-test systemd: [/etc/systemd/system/application.service:14] Executable path is not absolute, ignoring: pkill --pidfile /var/run/apps/application.pid Jun 10 18:49:43 centos7-test systemd: [/etc/systemd/system/application.service:14] Executable path is not absolute, ignoring: pkill --pidfile /var/run/apps/application.pid Jun 10 18:49:54 centos7-test systemd: [/etc/systemd/system/application.service:14] Executable path is not absolute, ignoring: pkill --pidfile /var/run/apps/application.pid Now the service is dead, pidfile is gone. So it stopped, but those messages concern me. What's going on, or where else can I look? Is there something other than pkill I should use to stop my python app? on CentOS 6 I used killproc, but that doesn't seem to be available in CentOS 7 by default so I switched to pkill. Thanks in advance!

I am trying to create a service wrapper (init.d script) around one of my favorite applications. The application creates both a PID and a lock file , and so I'm trying to use those to ensure that I can report accurate status of the application and prevent my service from starting multiple copies. Unfortunately, the application (or system) crashes from time to time, leaving the PID and lock files behind, so I can't just check for the existence of those files to determine if my application is running or not. The application does create a lock on the lock file, a POSIX WRITE lock, according to lslocks, but it seems that if I try to create a lock with flock -x -n "$file" echo dummy, the command succeeds, to my surprise. Deleting the file also succeeded (rm "$file"), as well as writing to it, which on a BTRFS system does make a small amount of sense, though doesn't make it any less aggravating. So, how can I query the file in such a way that I would know if the file has a lock (POSIX or FLOCK) on it or not?

After I killed the atd process by hand (sudo kill ), I can no longer start at jobs: [vagrant@localhost ~]$ echo ls | at 'now + 1 minute' job 6 at 2016-05-09 20:17 Can't open /var/run/atd.pid to signal atd. No atd running? Also, I see: [vagrant@localhost ~]$ service atd status atd dead but subsys locked [vagrant@localhost ~]$ service atd restart Stopping atd: [FAILED] Starting atd: [FAILED] [vagrant@localhost ~]$ I could reboot, since this is a Vagrant box expressly for playing around with, but I'd rather learn the "right way" to fix this. How do I get atd running again? (I'm running CentOS 6.6.)

It seems many programmers are happy with saving a PID to a file , and then later read and use the PID as if it was guaranteed to be the same process. It seems the general idea is that the odds are good enough to ignore. How can I simply demonstrate this problem? Ideally in such a way that existing shell scripts can be adapted to demonstrate this with the minimum of trial and error. Dummy example: foo & pid=$! echo $pid > pidfile do kill $! sleep 1 & until [ $pid -eq $! ] kill "$(cat pidfile)" # Kills sleep, not foo!

So my system entropy is low on my centos 6 VM. (137) and I installed haveged, Yum install haveged But when I go to start the process it instantly dies: Process is dead but sub system is locked Of course I did my research and found no answers why this is happening. I do see that the lock file is there. I've tried deleting it and restarting the service and that did nothing. I also do not see a PID file in var/run I installed this from the standard Repos with centos which I assume work since yum installed it fine.

Consider i am running just some basic command.. ls Now would the above command have a pid, when it was getting executed? If yes, then how can i determine that pid? when i try echo $! right after the ls command, it returns empty output. whereas if i execute ls & and then echo $! now it gives me the pid of ls command. Actually i got this question when i was looking at the below auditd logs.. type=USER_CMD msg=audit(12/16/2014 17:15:36.201:68342) : user pid=19247 uid=enginst auid=enginst ses=4229 msg='cwd=/apps/oradump/ora_temp_rdbms/OH3 cmd=chmod -R 777 11203 terminal=pts/2 res=success' type=USER_CMD msg=audit(12/16/2014 17:36:33.968:68753) : user pid=1801 uid=enginst auid=enginst ses=4229 msg='cwd=/apps/oracle/RDBMS cmd=chmod -R 777 11203 terminal=pts/2 res=success' Here, the above log says that "chmod -R 777" has been ran by the user enginst, and there is a pid as well. Now, can i conclude that the chmod command has been explicitly ran by the user, since the auditd logs doesn't show ppid (parent process id), which would be the case, if some script/program initiated it? However i have turned on process accounting now to check the above. But either ways, my question stands.. would commands like chmod, ls gets a pid when it gets executed? or no? or it gets a pid when it runs in background, whereas not in foreground?

We have 3 instances of redis running on a test server. For some reason, our start script which starts redis can write the wrong pid to a file. Here is what it's doing: su redis -c "redis-server /redis.conf & echo \$! > /var/run/redis_6379" If I chain together redis_6379 start && redis_6380 start && redis_6381 start and then I stop them like that and start them like that, after 10 or 15 iterations I'll encounter a pid in the start file that is off by 1. Does anyone know why that may occur?