How to find if a process a daemon ?

I have a scenario where I need to find if a process is a daemon process or not. This check needs to be done from within the process. I know there are no direct API's to do so. I have explored these options.

  1. ctermid() - this can be unsuccessful as per the man pages
  2. int devtty; if ((devtty = open ("/dev/tty", O_RDWR)) < 0) then it is a daemon. Are there any other cases, where this may not be true ?
  3. Since setsid() is used to detach from a terminal, perhaps getsid() can be used to check for process group leader and session leader.
  4. Look if parent pid is 1 or not. Can a daemon process have a ppid other than 1 ?

Are there more options ? I dont know if there is a best way to do this, but what would be the most appropriate way ?

Daemons can have any ppid and a ppid of 1 is no guarantee that you're a daemon. I like the open /dev/tty idea. It's portable. But of course it can fail for other reasons. No one ever did a
rm /dev/tty
on any of your systems? Also the process could be out of fd's, etc. Still it's the best way. Depending on the unix system, ther may be a non-portable way. Get the source code for ps and see how it finds this stuff out. But that is a lot of trouble to avoid opening /dev/tty. I would go with that.

I would build in a logic context so that you can be sure. For example, SIGHUP is a non-zero vector when a process is started. It is good practice to null the vector after one's fork/exec (in the child, of course), obviously to avoid the humiliation of having one's nice daemon code quit when the starter-upper terminates. So, then, your test could be "is my SIGHUP vector NULL?" and process accordingly. Use your OS facilities to good purpose, and let them help identify your context, too.

Can a daemon process have a ppid other than 1 ?

Any process guarded from SIGHUP signal as nohup process and detached from controlling terminal will have a ppid of 1, but they are not daemonized.

How about this - to check for the masking permissions ? I know its not a standard practice that needs to be followed before daemonizing a process but its more of a practice.

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)

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

Daemons have no controlling terminal.
Non-daemons have a controlling terminal.

Agreed.
ppid doesn't matter.

But what about a process started as nohup process and detached from controlling terminal ?
It has no terminal attached, I don't think it can be called as a daemon.

Started as a nohup or not doesn't matter. Most well written daemons will explicitly ignore signals that they want to ignore and install handlers for signals that they want to receive.

But if it's detached from it's controlling terminal, it is a daemon. This is exactly what happens when you restart cron or inetd from the command line. Since you don't think that processes with no controlling terminals are daemons, what is your definition of a daemon?

This is what my notion is -
All those processes without a controlling terminal need not be necessarily daemons and can remain as ordinary process.

Ok, let me clarify it this way.

For ex:

nohup ./check_process
detach it from terminal

[ check_process : checks whether a process is running or not ]

Since there is no terminal associated with check_process, is that a daemon ?