I wanted to use dm-tool to debug a problem I'm having (lxpanel > "Lock
screen" does not lock the screen, which I will report separately on that
package) so I tried "dm-tool lock" to verify if locking works at all.
Unfortunately, instead of locking the current VT (vt7), it opened a new
one and locked it instead (vt8).

After locking, I pressed ctrl-alt-f7 to return to vt7 and observed it
was still unlocked, then pressed ctrl-alt-f8 and entered my password to
unlock vt8. Upon unlocking, I was switched back to vt7.

Actually that's not what happens. dm-tool locks will just call the
Lock() dbus method on the current seat. In response to that, lightdm
will emit a dbus signal for locking, then switch vt to display a login
screen.

See the following thread [1] where I raised exactly those issues. There
are other threads on this, for example about lxsession [2].

That's because you don't have anything waiting for the dbus signal. If
you really want to use dm-tool lock (or switch-to-greeter), you need a
locker running on the session, like light-locker or the GNOME ones
(gnome-shell, unity or whatever).

[1] http://lists.freedesktop.org/archives/lightdm/2014-January/000494.html
[2] https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1205384

In #780024 I discovered the failured the root cause of my inability to
lock the screen was that I did not have xscreensaver installed and did
not replace it with an alternative screen locker. It appears that
light-locker is the appropriate alternative for lightdm. But dm-tool(1)
doesn't mention or cross-reference via SEE ALSO light-locker(1). I think
it should, since without it, "dm-tool lock" just looks broken.

After installing light-locker, logging out and logging in, this is the
new behaviour I observed if I trigger a screen lock (either via lxpanel >
lxsession-logout > Lock Screen, or via 'dm-tool lock'):

1. A new VT is opened for the locker dialog on vt8.

2. If I ctrl-alt-f7 to go back to vt7, a message telling me the session
   is locked and I'll be redirected in a few sessions is displayed. After
   waiting a few seconds, I am redirected back to the locker dialog on
   vt8.

Therefore, I'm retitling this bug and dropping severity to minor, as it
is simply a doc problem now.

Please also consider if lightdm should at least have Suggests:
light-locker.

Thanks,
Ben

Sure. Makes sense. And aligns with my second comment on this bug.

OK. Read them. So to sum up, the way the system is architected now,
there's really no way for lightdm to know if a lock actually occurred or
not.

Once I discovered light-locker needed to be installed, which took in
excess of an hour of investigation to discover, I got it sorted out, so
I guess in absence of fixing this at the architecture level (which I
understand won't be cheap), just a little bit of doc will go a long way
to at least help the users who are observant enough to notice the screen
isn't actually being locked, or who go looking to see if disabling
xscreensaver needs anything else to keep locking working.

Yep, that's all it took. But wow, what a big accident waiting to happen
for unsuspecting users! Some time ago, I had disabled xscreensaver to
keep my session as light as possible, and the session appeared to be
getting locked by lightdm anyway, so I didn't think anything of it. It
was not until lxlock failed to produce any visible result when I pressed
the "Lock Screen" button that I went looking and found this issue, so I
don't know how long it has been that my session was not actually being
locked!

I'm happy to leave this one on the books as a pair of minor doc bugs to
xref the relevant man pages. But I earnestly hope that upstream sorts
this out in the next release.

Thanks,
Ben

Indeed.

The whole procedure is broken by design. The dbus methods which
dm-tool/lightdm use
    org.freedesktop.DisplayManager.{Session|Seat}.Lock()
    org.freedesktop.login1.Session.Lock()
don't return any value to the caller.

That's why you shouldn't call it unless you know something will do the
locking.