This does suggest unity8-dash is starting but either
1. there is no mir server, such as unity8, running
2. MIR_SOCKET is not set to the correct mir server socket
3. the permissions on the socket file mean dash cannot connect
We rely on upstart to ensure Dash starts when unity8 claims to be ready to accept connections.
Upstart starts unity8, and puts it in the "starting" state. When unity8 is ready to accept client connections, it emits a SIGSTOP. Upstart intercepts this and SIGCONTs unity8. It then can start anything which requires the unity8 job to be "running" - such as unity8-dash.
It's also upstart's job to set the MIR_SOCKET env var, and other env vars required. And to ensure permissions are correct.
So something in the above has gone wrong.
I am aware of unity8 not always shutting down correctly, which might leave cruft behind. But I wold have thought upstart was cleaning that cruft up, and only launching unity8-dash after a working unity8 had started.
This does suggest unity8-dash is starting but either
1. there is no mir server, such as unity8, running
2. MIR_SOCKET is not set to the correct mir server socket
3. the permissions on the socket file mean dash cannot connect
We rely on upstart to ensure Dash starts when unity8 claims to be ready to accept connections.
Upstart starts unity8, and puts it in the "starting" state. When unity8 is ready to accept client connections, it emits a SIGSTOP. Upstart intercepts this and SIGCONTs unity8. It then can start anything which requires the unity8 job to be "running" - such as unity8-dash.
It's also upstart's job to set the MIR_SOCKET env var, and other env vars required. And to ensure permissions are correct.
So something in the above has gone wrong.
I am aware of unity8 not always shutting down correctly, which might leave cruft behind. But I wold have thought upstart was cleaning that cruft up, and only launching unity8-dash after a working unity8 had started.