pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) (09/23/88)
Hi, I have a question about daemon creation. I have always used the following approach whenever I needed to create a server/clients system. I fork a process with superuser privileges which sets up all the communication protocols and then waits for somebody to talk to it. The user processes communicate asyncronously whenever they please. This works fine except for the fact that the daemon has to come on usually at boot time of machine. This is a big problem if the daemon has to a lot of book-keeping work from time to time, like communication statistics, and hence becomes a CPU hog. Nicing it is one way. But is there another way to solve this problem ?? If the daemon need not be alive for too long 'before' the first client tries to talk to it, then I have the following scheme. The first user, when he tries to talk to the daemon finds the communication protocol not set up (like FIFO files in /tmp) and then figures out that it is the first user and hence fires the daemon up. Now it could die, leaving UNIX to make the undying child process the child of root and hence a true daemon. But this is clumsy because the user has to relogin. Any suggestions are welcome. Pratap. .... pratap%hpcllcm@hplabs.hp.com
quan@hplabsb.UUCP (Suu Quan) (09/24/88)
In article <6840003@hpcllcm.HP.COM>, pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) writes: > The user processes communicate asyncronously whenever they please. This works > fine except for the fact that the daemon has to come on usually at boot time > of machine. > > This is a big problem if the daemon has to a lot of book-keeping work from > time to time, like communication statistics, and hence becomes a CPU hog. > Nicing it is one way. But is there another way to solve this problem ?? > > If the daemon need not be alive for too long 'before' the first client tries > to talk to it, then I have the following scheme. The first user, when he tries > to talk to the daemon finds the communication protocol not set up (like FIFO > files in /tmp) and then figures out that it is the first user and hence fires > the daemon up. Now it could die, leaving UNIX to make the undying child process > the child of root and hence a true daemon. Don't really know if this will solve your problem - because I don't really understand it -, but did you consider leaving 'inetd' to spawn your server daemon whenever there is a request for connection from a client ?