>> Mikkel L. Ellertson wrote: >>> Jon Trauntvein wrote: >>> >>>> Mikkel L. Ellertson wrote: >>>> >>>> >>>>> Jon Trauntvein wrote: >>>>> >>>>> >>>>>> Greetings, >>>>>> >>>>>> I am developing a daemon application to handle datalogger >>>>>> communications. I have developed the init script that is >>>>>> included at the bottom of this mail based upon examples that >>>>>> I found on the web. This script runs very >>>>>> well from the command line. However, when I attempt to use >>>>>> the gnome server configuration tool to start csilgrnet, the >>>>>> tool locks up and has to be aborted. I have searched in vain >>>>>> for guidelines for writing init scripts and have no idea what >>>>>> the gui is looking for and not finding. Any assistance or >>>>>> advise would be gratefully accepted. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jon Trauntvein >>>>>> >>>>>> >>>>> For a guide to writing them, look at the documentation for the >>>>> initscipts package. The file you are looking for is called >>>>> sysvinitfiles. >>>>> >>>>> Mikkel >>>>> >>>> I found the above referenced file and have studied it in detail. I >>>> thank you. >>>> >>>> >>>> My original problem remains, however. That is, I can execute my >>>> script >>>> on the command line to start and stop the daemon process. If, >>>> however, >>>> I attempt to start the daemon using the services configuration GUI >>>> provided by gnome, the gui will lock up and I will have to kill it to >>>> close it. I have found, through experimentation, that, if the gui is >>>> in >>>> this locked state, I can actually bring it out by running the script >>>> from the command line to shut the daemon down. The gui will then pop >>>> up >>>> a dialogue indicating that the daemon has been started. >>>> >>>> I am convinced that my script is finishing because I can see evidence >>>> that the lock file is being generated by the call to touch. Again, >>>> there is absolutely no problem when this script is run from the >>>> command >>>> line or when I am starting or stopping the run level. >>>> >>>> >>>> Regards, >>>> >>>> Jon Trauntvein >>>> >>>> >>> I didn't see anything wrong with it when I looked at it, but I do >>> not use the GUI, so I could be missing something. One thing you may >>> want to check on is the permissions and ownership of the script. >>> >>> Mikkel >>> >> To go along with the permissions thing, make sure your SELinux context >> is correct. I find that SELinux is the cause for *many* problems if you >> don't remember to accommodate for it. >> >> Justin Willmert > > The script is owned by user root and has rx permissions set for the user > group and others (rwx for user). I'm not sure exactly what you mean by > "SELinux context". I can report, however, that the script is being run. > I added echo statements to the script that output comments to a log file. > I was able to verify that everything in the script ran up until the point > where the exit statement was reached. I can also tell you that the return > value sent with exit is 0. > > I have looked at the source and the man page for system-config-services. > The man page reports that some services must be run from the console in > order to be started. It fails to elaborate on causes beyond this. My > service, when enabled to run as a daemon, will invoke the following code: > > pid_t pid, sid; > pid = fork(); > if(pid < 0) > exit(-1); > if(pid > 0) > exit(0); > umask(0); > sid = setsid(); > > In the source for system-config-services, it looks like the program is > invoking popen() on the output of the service script. The best that I can > figure is that the EOF signal is not being received by the program. Could > this be happening because my daemon is failing to close its standard > output device and, because it is open, no EOF ever comes while the daemon > is running? > > Regards, > > Jon Trauntvein I just added code to my daemon that closes the standard IO handles. This does indeed seem to be the cause of system-config-services locking up when the daemon is started. It was waiting for an EOF that wouldn't come until the daemon was closed. This lack of EOF didn't matter for any of the other methods because they were not using popen() to monitor the output (they were just examining return values). I thank all of you for your assistance on this matter. Regards, Jon Trauntvein
