В Wed, 12 Jun 2013 16:02:51 +0100
Mel Gorman
On Wed, Jun 12, 2013 at 03:43:38PM +0100, Mel Gorman wrote:
On Wed, Jun 12, 2013 at 04:33:37PM +0200, Jan Engelhardt wrote:
On Wednesday 2013-06-12 16:21, Mel Gorman wrote:
Of course PidFile is preferred in this case than lying about service state. This a at least will properly track daemon status.
Ok done and preliminary testing looks ok. The package should be up to date with all feedback. Is there anything else that should be fixed up? Any suggestions on what devel project to submit it to before pushing to factory?
Well, making the daemonization optional, perhaps through the use of a flag like smbd -F would allow you to use the simple ForkingType.
Unlike the other patches, that would be a fairly sizable deviation from upstream for opensuse. It would be a fairly straight-forward patch but is the forking type so bad that such a move is justified?
This is what the numad patch ends up looking like complete with update to service file. I've no problem carrying it as part of the package but if I would appreciate being slapped with a cluebat as to why the systemd forking type is so bad.
Both simple and forking are bad actually :) Both have the same problem - they assume service is available as soon as program is started/forked. Which is often wrong - some programs may need long time to start up. Best is socket activation, but it requires comprehensive support from application. Second best is notify. This is technically trivial to add, it is a single call to inform systemd that service has finished initialization and is ready. simple is OK for "leaf" services that do not provide services themselves. But I think you mentioned that your program accepts requests. Forking is OK when done right, but I have seen programs that fork multiple times and this may confuse systemd as to which one is the main process. That is where PID file comes handy.
I guess the obvious explanation is that if there are two services A and B where A is forking and B depends on A then there is a race where B can be up and running before A is ready to accept requests. This potentially leads to errors during startup that are very hard to trigger. Such a scenario should not be a problem with numad but maybe there are other cases.
If you are sure numad never races with other programs that require it - just use forking, it has no real advantage over simple and simplifies maintenance. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org