"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Tim Legant <[EMAIL PROTECTED]> writes: > >> Coupled with the desire for multiple instances, the pid file should >> probably reflect the port number: >> >> /var/run/tmda-ofmipd:8025.pid >> >> or something similar. > > Yup. I notice some daemons create a subdirectory under /var/run/ to > house their multiple pid files. This might be a bit cleaner than > writing all of them to /var/run/.
That could work. What would we name the files, then? If the directory is called, e.g., 'tmda-ofmipd', then repeating 'tmda-ofmipd' seems redundant (and tedious for typing). >> My current version of the patch cleans up the pid file on termination, >> so the only reason that a pid file would exist is if the daemon >> aborted. > > If I 'kill -9' tmda-ofmipd, will the pid file be cleaned up, or will > it linger? 'kill -9' is an abortion. It doesn't give the application a chance to clean up. So no, the pid file will still be there. 'kill -TERM', on the other hand, is handled properly, cleans up the pid file and shuts down the Python interpreter in an orderly fashion. I'm sure you're aware, but 'kill -9' should only be used in dire circumstances, when nothing else works. We should probably clean up existing connections before exiting, too, but this is a patch for one purpose. If I were to start cleaning up all the little things that I know need to be fixed in tmda-ofmipd, it would be weeks before I had something runnable again. >> A warning of some sort seems in order, but perhaps the warning >> should simply be printed and then the existing pid file should be >> overwritten. > > Why is a warning in order? Because in all normal application end cases the pid file will have been deleted. If you ever receive the warning, it's an indication that something went wrong -- and that you should probably figure out what. If you used 'kill -9', you know what happened and the warning won't keep tmda-ofmipd from running. If you *hadn't* used 'kill -9', then maybe there's a problem you should be aware of. Silently overwriting the pid file will leave you blissfully unaware. >> If an instance is already running on the same port, tmda-ofmipd will >> already have abended with a traceback about not being able to bind the >> port, since that occurs before we try to create the pid file. Does >> this behavior (print warning, but continue) make more sense? > > I don't want people to have to manually remove pid files for any > reason before they are able to restart tmda-ofmipd; this just doesn't > jive with standard daemon behavior that I've seen. I'd vote to > just overwrite without printing a warning. So we're in agreement but for the warning. Does my explanation above change your thoughts on this? Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
