What exactly does it mean to run a process in the "background"?

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.