On Wed, Jun 12, 2013 at 09:04:24PM +0400, Andrey Borzenkov wrote:
? Wed, 12 Jun 2013 16:02:51 +0100 Mel Gorman <mgorman@suse.de> ?????:
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.
Not as such. It monitors the systems and shoves processes into cpusets to improve memory locality. It receives messages but only from an invocation of numad to alter settings at runtime. I'm not anticipating any weird races from this.
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.
Ok.
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.
From a maintenance point of view it's roughly equal difficulty to me. I'll leave it as a simple service running in foreground for now simply because there is no real advantage between this and running as forking for such a simple daemon.
Thanks. -- Mel Gorman SUSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org