[systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

Lennart Poettering  wrote in message <20141020173828.GA4509 at gardel-login>:
> They should probably adopt socket activation anyway, otherwise they'd
> be quite annoying on multi-user systems if lingering is used.

I am brainstorming here, but would it make sense to add hooks to logind
when a session is started/closed (both system hooks and user hooks)?

For instance when I log into X, my .xprofile contains
    systemctl --no-block --user  start "xsession@${DISPLAY}.target"
to start my user services.

I need to make sure that everyway I have to log into X (with a *DM, with
startx, with xinit) I somehow source .xprofile.

Stopping the started services also involve some contorsion. When I quit X
most of the services started by xsession@$DISPLAY fails because X is no
longer available, and I don't want systemd to try to restart them in this
case. So I need to stop these services whenever X exits.

So inside xsession at .target, I launch xwatch at .service:

[Unit]
Description=Watch for X on display %I
BindsTo=xsession at .target

[Service]
Environment=DISPLAY=%I
SyslogIdentifier=xwatch@%I
ExecStart=/bin/sh -c 'exec %h/mine/script/services/xwatch %I'
Nice=19

[Install]
WantedBy=xsession at .target

with $ cat ~/script/services/xwatch
#!/bin/sh
xprop -spy -root XFree86_VT
systemctl --user stop "xsession@$1.target"

So whenever my X session stops, xwatch will stop xsession@$DISPLAY.target,
and thus stop all services files that I configured to be PartOf
xsession at .target. For instance xcompmgr at .service:

[Unit]
Description=xcompmgr on display %I 
PartOf=xsession at .target
ConditionFileIsExecutable=/usr/bin/xcompmgr

[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/xcompmgr
Restart=on-failure
RestartSec=3
StandardOutput=null

[Install]
WantedBy=xsession at .target
Also=xwatch at .service

It works really well, I can even log onto different X sessions and have the
corresponding services launched into the different $DISPLAY, but having
some close hooks in logind would help getting rid of xwatch.service.