[PATCH Weston 1/1] desktop-shell: implement autolaunch

[Pekka Paalanen]

On Fri, 24 Oct 2014 14:47:00 -0700
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Fri, Oct 24, 2014 at 01:18:51PM +0300, Pekka Paalanen wrote:
> > > And, while you're at it - as this was written for kiosk mode, it spawns a
> > > shell script which just restarts the video player in a loop. Can we please
> > > add an autostart param to weston_client_run/start (as a new enum with
> > > WESTON_CLIENT_RESTART, not bool) and to the config (as a bool) which lifts
> > > most of
> > > desktop_shell_client_destroy/check_desktop_shell_crash_too_early/respawn_desktop_shell_process?
> > 
> > I'm not sure that's feasible. Watching the process exit is not used to
> > trigger respawn for weston-desktop-shell, but losing the wl_client is.
> > These two events happen in arbitrary order, and we recently fixed a
> > related bug by exactly not respawning based on process exit. We want
> > weston-desktop-shell to respawn if the compositor disconnects it, even
> > if the actual process gets left behind due to malfunction.
> > 
> > Restart for autolaunch OTOH would be based on process exit rather than
> > losing the connection.
> > 
> > IOW, weston_client_start() and the existing respawn mechanism are
> > intended for special purpose known clients, while the panel
> > launchers and the autolaunch feature are meant for running arbitrary
> > programs (that might not even be clients themselves/directly or at all).
> > 
> > I'm not sure if adding restart to autolaunch is in scope... there are
> > many aspects to configure for restart (delays, when to give up)
> > so I'd rather maybe keep with the script. Or systemd user session.
> > After all, the autolaunch is just a quick'n'useful hack when no session
> > manager (systemd or other) is available.
> 
> Hmm, the several special cases / hacks here maybe suggests some
> generalization is needed?

The two cases I described are very different. weston_client_start() is
usually used to launch DE helper applications that need special
privileges, and therefore the Wayland connection is created
before-hand. It is part of our security mechanisms.

What would you refactor here?

> Also, for X, there is typically a .xinitrc, .gnomerc, or similar that's
> executed as a shell script during system launch.  Do we have plans for
> adding something similar for weston?  Like a .westonrc?

This patch adds exactly that. Well, a place to tell what to execute
automatically when the compositor becomes ready, anyway.

Btw. there is already also the "primary client" feature in Weston. An
application may launch Weston and be the only normal client to Weston
then. Weston will quit when this client disconnects. It is controlled
by WESTON_SERVER_SOCKET environment variable, which is set to an open
file descriptor number. Weston does not create a listening socket in
this case. Obviously that is a very different case than start-up
scripts.

> If not, perhaps this feature gives us a place for hanging startup
> scripts?

Yes. We already have lots of logic to find a weston.ini file, why would
we add more logic to similarly find a .westonrc? We can just say in
weston.ini what to execute.

I think that is also more clear, because the only file that Weston
needs to find on its own is weston.ini, and so it's a single point of
failure rather than finding two, if something goes wrong.

Note, that you can have any number of autolaunch entries. You don't
need a separate script if you just start a bunch of one-off apps.

> (Not saying that shell scripts are the best way to do autostart of
> applications, but it has been a tradition...)

Well, if you are building a DE, you write a plugin for it in any case,
and that plugin can then spawn and manage the helper apps if it needs
to.

This autolaunch on the other hand is very much a hack, which is useful
in the odd cases where writing a plugin is not appropriate. A demo setup
that automatically starts a video player at boot, for instance, which is
the very case behind this patch.

One might see this similar to script based init vs. systemd. I do
like systemd, but I don't think we should make Weston a generic process
manager. For the odd hacks, being able to run scripts and other random
stuff just via weston.ini is useful.


Thanks,
pq