Woah, don't hit enter on the description line....

The problem experienced is when attemping to run two Xorg 1.16 servers non-root from startx in seperate virtual terminals.  The first starts ok, the second fails when attempting to open its virtual terminal.  From Xorg.*.log of the second:

 [  8259.535] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c10
 [  8259.536] (II) xfree86: Adding drm device (/dev/dri/card0)
 [  8259.536] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0
 ...
 [  8259.549] (++) using VT number 6
 [  8259.554] (--) controlling tty is VT number 6, auto-enabling KeepTty
 [  8259.554] (EE) 
 Fatal server error:
 [  8259.568] (EE) xf86OpenConsole: Cannot open virtual console 6 (Permission denied)
 [  8259.573] (EE) 
 [  8259.578] (EE) 

From journalctl:

 Jul 30 14:41:59 habeascorpus.pigworks.openss7.net login[8764]: LOGIN ON tty5 BY brian
 Jul 30 14:42:17 habeascorpus.pigworks.openss7.net systemd-logind[601]: cannot mute VT 5 for session c15 (-16/17)

Looking at src/login/logind-session.c where this error message is generated, it uses sigprocmask to block USR1 signal and calls sd_event_add_signal().  sd_event_add_signal() uses pthread_sigmask() to check that USR1 is blocked (which it isn't for the second Xorg server) and returns -EBUSY (-16 in error message).  sigprocmask() is for use only in single-threaded programs.  It appears that sigprocmask() is blocking USR1 on the main thread and pthread_sigmask() is checking it in the running thread.  This results in sd_restore_vts() setting the permission on the virtual terminal back to root, but the Xorg server is still allowed to take control of the session.  The result is that xf86OpenConsole() has insufficient permissions to open the virtual terminal.

Please correct.

I tried recompiling 215 with pthread_sigmask instead of sigprocmask in sd_prepare_vts() and it still behaves the same.  The -EBUSY must be returned from checking whether the signal is installed on s->manager->event in sd_event_add_signal() instead of the pthread_sigmask() check.  Is this the case of a per-session signal being managed as a manager-wide signal?

Should be fixed in git.