Hello Clint! Thank you for such a solid response! I believe that the output from such utilities should be human-friendly. This means that the messages should be understood without explanations. OTOH the message must carry the sense strictly tied to a use case. So if I start the service I want to know if the service was already running or it was started successfully or failed -- no more, no less. 'start/running' in this case doesn't make the difference between 'already running' and 'started successfully' (without a crib). This is human-oriented interface, Clint, so when I run the command I want be sure about the state when the command returns. Any 'shoulds' or 'woulds' doesn't fit to this case.
Now to the bug-reporting business. I am sorry, but I'm slightly apart from the upstart project. So if you liked my advices, then you or any interested person will take all required actions to make them realized. Thank you! You were really much frendlier than the upstart program btw. ;) On Sunday 07 November 2010 10:55:50 Clint Byrum wrote: > Hello midenok, thank you for taking the time to file this bug > report and help us make Ubuntu better. > > I'll try to respond to each of the issues raised: > > The output is actually quite informative, its just different from a > sysvinit script. It is telling you a few things: > > start/running -- start means that upstart things the job *should* > be running, and it will make sure that happens, or, if the job has > 'respawn', that it stays that way. running means that the exec line > and any post-start have been executed.. the job is *running*. This > is also a clue that the 'started' event for the job has been > triggered. > > The pid listed is the pid that upstart will track and watch for > respawns. > > stopped/waiting -- this means that upstart thinks the job should, > in fact, be stopped. waiting simply means upstart is in its "do > nothing" state for this job.'man initctl' lists the other states > that may be returned. > > I have to agree that the 'unknown instance' error is cryptic. To be > fair, 'status' is really the way to check on the, well, status of a > job. > > If you mean that upstart needs to provide *the output of the > commands themselves* in a more friendly way than 'console output' > povides, I agree, and so do many others in bug #328881 > > The reload stuff is a bit inconsistent, agreed. > > If the job's process is killed and you have said 'respawn', then > upstart most definitely *does* log the respawn: > > Nov 7 00:51:53 box init: foo main process (16464) killed by TERM > signal Nov 7 00:51:53 box init: foo main process ended, respawning > > The bit about the cryptic error on stopping an already stopped job, > and reload conf behavior inconsistency, are probably both good > bugs. > > You will probably want to report them each as a single bug report, > directly upstream at https://bugs.launchpad.net/upstart > > I'm closing this particular report though, because it contains > multiple bug reports, some of which are duplicates, some of which > are simply opinions. Please re-open each individual issue if you'd > like them addressed directly. > > ** Changed in: upstart (Ubuntu) > Status: New => Invalid -- upstart is extremely non-friendly https://bugs.launchpad.net/bugs/669016 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
