On Tue, 2010-04-13 at 17:44 +0000, Andrew Pollock wrote:
> It probably makes sense to be consistent with
> http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-
> generic/iniscrptact.html, doesn't it?
>
No, there's no reason for Upstart to be consistent with the LSB if it
doesn't make sense -- I assume that LSB future will mandate Upstart,
after all.
For example, given the above return codes:
0 program is running or service is OK
this one makes sense for Upstart
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
these make no sense for Upstart
3 program is not running
"not running" is too vague; what about "is starting", "is being
stopped" or "will be restarted" ?
4 program or service status is unknown
service status can *never* be unknown with Upstart
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
On Tue, 2010-04-13 at 17:44 +0000, Andrew Pollock wrote:
> It probably makes sense to be consistent with refspecs. freestandards. org/LSB_ 3.1.1/LSB- Core-generic/ LSB-Core- iniscrptact. html, doesn't it?
> http://
> generic/
>
No, there's no reason for Upstart to be consistent with the LSB if it
doesn't make sense -- I assume that LSB future will mandate Upstart,
after all.
For example, given the above return codes:
0 program is running or service is OK
this one makes sense for Upstart
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
these make no sense for Upstart
3 program is not running
"not running" is too vague; what about "is starting", "is being
stopped" or "will be restarted" ?
4 program or service status is unknown
service status can *never* be unknown with Upstart
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?