Toaster cannot start overriding the lock file, simply because the lock file may have not come from an unclean shutdown of toaster.

If there is a lock file, it may be there for a number of reasons, and there is no way to detect automatically why it is there and what the best course of action to side step it.

The "stop" command of toaster forcefully takes everything offline, even processes not started by toaster. Toaster should start without error after that. I do not think that automatically start the system overriding anything existing on the system is an expected UNIX behaviour. e.g. Apache web server will refuse to start if the configuration or environment are bad, and will not automatically attempt to rectify problems so it can start.

I suggest that we document the fact that the "stop" command of toaster will clean stale information from the disk, and that if "start" encounters errors, the user should run "stop" and then "start" commands with the caveat that it may disrupt other ongoing setups.

Will not fix. Reasons mentioned above.

I'm sorry but I don't agree with this. If we do not currently have the means to determine whether a lock file is valid then we need to add it. The start script is intended to manage the two separate services here and the user expects the script to just manage those, not give up if something is slightly unusual with one of them; it's especially suboptimal if the "unusual" situation is easy to trigger by the user.

The toaster start script doesn't just look at bitbake lock, it verifies multiple conditions before attempting to start needed services.

I have several concerns here:

1.  I am not aware of any Unix service that will force a start anyway if something goes wrong during the start of the service. The normal Unix policy is to not start and prompt the user to correct what's wrong. I do not think that it would be a good Toaster policy to do something that is not Unix-like.

2. There is no general rule to see if the system lock is valid or not. The lock can fall in any detectable configuration through normal usage, and we don't have any mechanism to detect whenever the lock is invalid.

Even if we could reliable detect if the lock is genuine or not:

3. If the lock is genuine, Toaster should not start, because it is already running there.

4. If the lock is not genuine, something really bad happened. Toaster should not attempt to start because:
4.a) probably Toaster can't run normally due to some systemic error
4.b) it will destroy evident of Toaster running abnormally
   Because of the both reasons above, I think that it's not a good idea to start Toaster if the lock is determined to not be genuine.

Given all 4 concerns above, I see no use case on when Toaster actually COULD start when it finds that it should actually be running. 

The only sensible course of action would be to run the stop command, and then attempt starting again, but I recommend against automatically do so because point 4. above.

1. The usage for this script is not really like a unix service, where it's started on boot and stopped on shutdown in an unattended fashion - it's something the user is expected to interact with on a regular basis. The situation we are discussing is also not an issue of invalid configuration (i.e. that the user has caused and can easily troubleshoot), it's something possibly broken in the software itself, so the comparison with Apache not starting isn't valid.

2. Why is it not possible to determine if the lock is valid?

3. I somewhat agree that it shouldn't start if the lock is valid - the key word though is *if*. However, if it does fail at this point the script *must* explain why directly - it must not error out with a generic error such as "failed to start server".

4. You say "something really bad happened", but we've already seen that this situation can be triggered by the user not shutting down the server explicitly. Frankly I do not think the user should have to, and they should not have to do anything manual to clean up after it when they don't - the only thing achieved by making users jump through this hoop is increasing their frustration, particularly if we're going to just advise them via the documentation to manually stop the server anyway.

Changed the error checks to more specific cases; automated recovery if the bitbake server is down, and the web server is up, which is the most common failure mode.

Implementation complete, queued to be sent on the bitbake-devel on next submission cycle.

This is fixed in master.