Quote:
Originally Posted by
matrixmadhan
Any process guarded from SIGHUP signal as nohup process and detached from controlling terminal will have a ppid of 1
Not true. Any time any daemon which happens to be ignoring sighup forks, it creates a counterexample to this statement. (init could fork without creating a counterexample, but it never ignores hup)
Quote:
Originally Posted by
matrixmadhan
but they are not daemonized.
Actually any process that happens to meet these criteria are daemons. No controlling terminal means the process is a daemon. Whether or not a process is a daemon has nothing to do with the ppid or what signals it is ignoring.
With most versions of unix when you log in on the system console, the ppid of your login shell will be 1. Before the rise of tcp/ip the ppid of every login shell was 1. None of these login shells are daemons, they all have controlling terminals. You still may have other getty lines in /etc/inittab. Each such line is a potential interactive shell with a ppid of 1. But most other children spawned by init do not open ttys and remain daemons.
When a process exits, its children become owned by init. This does not impact whether of not those children are daemons. Some are. Some aren't.
cron will not have a pid of 1. Every time cron spawns a process, that new process is a daemon. Each of these daemons will not have a ppid of 1... their ppid will be pointing to cron.
When you need to determine if a process is a daemon or not, the ppid is completely irrelevant. Daemons and non-daemons can have a ppid of 1. Daemons and non-daemons can have a ppid other than one.
Daemons sometimes choose to
not ignore sighup. Both inetd and init itself are examples of daemons that are listening for a HUP. When they get one, they reconfigure themselves. But it is more common for a daemon to be ignoring HUP.
It really it very simple.
Daemons have no controlling terminal.
Non-daemons have a controlling terminal.
Examples of stuff that have no bearing on a process' daemon status...
pid
ppid
signal mask