I use lightdm as a DM and I often have multiple (usually two) X sessions on different VT-s. In that setup I often (always?) observe that console-kit loses track of active session resulting in things like automatic screen lock not working. Also, I see messages like these during initial startup and VT switches: console-kit-daemon[2882]: WARNING: Unable to activate console: Inappropriate ioctl for device console-kit-daemon[2882]: WARNING: Error waiting for native console 10 activation: Inappropriate ioctl for device console-kit-daemon[2882]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device console-kit-daemon[2882]: WARNING: Error waiting for native console 11 activation: Inappropriate ioctl for device Using ktrace and fstat I determined that console-kit tries to do ioctl on a file descriptor that's been revoked (not associated with any file): 2821 100888 console-kit-daemon CALL ioctl(0xa,VT_ACTIVATE,0x9) 2821 100888 console-kit-daemon RET ioctl -1 errno 25 Inappropriate ioctl for device I determined that originally that descriptor is produced by opening /dev/tty. I haven't been to determined when it gets revoked. However, I think that this already reveals the problem. I think that on FreeBSD /dev/tty is a controlling terminal. I am not sure what the controlling terminal of daemons like lightdm and console-kit-daemon is supposed to be and how it should behavior during operations like VT switches. Maybe there is some underlying problem in FreeBSD terminal code. However, given the type of operations that console-kit does on that terminal, I think that opening /dev/ttyv0 would be more appropriate and that file descriptor would be more stable. In fact, I patched console-kit to do that and since then I do not see any problems like I saw before. The descriptor is always good: root console-kit-daemon 3974 10 /dev 124 crw------- ttyv0 r
Created attachment 258654 [details] proposed patch patch-src_ck-sysdeps-unix.c Not sure if this is the best that can be done, but that's what I currently have.
TLDR of my understanding. /dev/tty is a device for the controlling terminal of the process. The process can detach or lose the controlling terminal, either voluntary or involuntary. /dev/ttyv0 is a device for VT1 associated with the system (video) console. It should always be there if the system has video console.
Almost 2 years ago I was working on fixing concurrent sessions in (our closed fork of) x11/sddm. It resulted in a substantial work done on the ConsoleKit side, which is now present in the Ports tree. The SDDM part was a bit ugly, so I was reluctant to opensource it back then. While hacking on this problem I also bumped into a similar VT management issue. I don't remember all the details now, but the issue stems from the fact that if you want to do an ioctl() on ttyvN then you should pass N+1 as an argument. So one of my patches for SDDM was fixing functions that convert between device paths "/dev/ttyvN" and integer TTY numbers: QString path(int vt) { // ioctl interface returns N+1 for ttyvN char c = (vt <= 10 ? '0' : 'a') + (vt - 1); return QStringLiteral("/dev/ttyv%1").arg(c); } int number(QString path) { if (path.startsWith(QStringLiteral("/dev/"))) path = path.mid(5); if (path.startsWith(QStringLiteral("ttyv"))) path = path.mid(4); else path = path.mid(3); // "tty" int ret = path.toInt(nullptr, 16); #ifdef __FreeBSD__ // ioctl interface returns N+1 for ttyvN ret++; #endif return ret; } I think this is exactly the problem you see with LightDM. The warnings you see in ConsoleKit are actually caused by LightDM asking about wrong TTYs. If you point to me the LightDM code that calls ConsoleKit, I'll look into that more closely.
(In reply to Gleb Popov from comment #3) I think that this could be a different issue. ConsoleKit opens "/dev/tty" (note absence of "v" and any number) just once on startup. As far as I can tell, ConsoleKit does not take any input from lightdm for that. Then ConsoleKit uses that file descriptor forever. The problem is that the descriptor gets revoked. The ConsoleKit code is here: https://github.com/ConsoleKit2/ConsoleKit2/blob/master/src/ck-sysdeps-unix.c#L295 I think that ConsoleKit really wants to open a console device but opens current controlling terminal instead. At the same time, it could be that lightdm uses a wrong controlling terminal and ConsoleKit somehow inherits it. On the other hand, I think that lightdm and ConsoleKit communicate through dbus. Also, I see in FreeBSD patches for lightdm that it should use /dev/console for working with VT-s. See x11/lightdm/files/patch-src_vt.c. Original code: https://github.com/canonical/lightdm/blob/main/src/vt.c
(In reply to Gleb Popov from comment #3) This is probably what you had in mind: x11/lightdm/files/patch-src_x-server.c The code looks correct but I think that it is not relevant to ConsoleKit.
A looked at the code a bit and the problem is still unclear to me. My gut feeling is that there is an off-by-one error somewhere in the vt handling within LightDM itself. It turned out, that it doesn't rely on ConsoleKit to manage vts, but does it on its own. ConsoleKit is only used to create and lock/unlock sessions. Back to your original question, what makes you think the ConsoleKit closes the descriptor? You can inspect ConsoleKit's descriptor table with the lsof command.
(In reply to Gleb Popov from comment #6) The descriptor is not closed, it's revoked. I used fstat -p and procstat -f to check for that (I prefer native tools). I am running the patched ConsoleKit right now, so the output is good (from both tools): USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root console-kit-daemon 3974 10 /dev 124 crw------- ttyv0 r PID COMM FD T V FLAGS REF OFFSET PRO NAME 3974 console-kit-daemon 10 v c r------- 12 0 - /dev/ttyv0 Previously it looked like this: USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root console-kit-daemon 3974 10 PID COMM FD T V FLAGS REF OFFSET PRO NAME 3974 console-kit-daemon 10 v x r------- - 0 - -
I now remember that we made ConsoleKit open /dev/console to fix another bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221452#c40
(In reply to Gleb Popov from comment #8) Let me read that bug report. But I think that the patch was correct and the current code is wrong. It does not open /dev/console, it opens current controlling terminal ("/dev/tty").
(In reply to Gleb Popov from comment #8) Maybe upstream ConsoleKit code changed since those times. What I see proposed in bug 221452, in comment 39: use /dev/console instead of /dev/ttyv0 (at least, that's the verbiage). I am not sure what kind of difference that made. What is happening now: /dev/tty (controlling terminal) is used. For reference, this is what the removed patch was: --- a/src/ck-sysdeps-unix.c +++ b/src/ck-sysdeps-unix.c @@ -308,6 +308,13 @@ ck_get_a_console_fd (void) } #endif +#if defined(__FreeBSD__) + fd = ck_open_a_console ("/dev/ttyv0"); + if (fd >= 0) { + goto done; + } +#endif + #if defined(__NetBSD__) fd = ck_open_a_console ("/dev/ttyE0"); if (fd >= 0) {
(In reply to Andriy Gapon from comment #10) Running lsof -p $(pgrep console) | grep /dev on two different laptops and FreeBSD versions gives me console-k 36175 root 12r VCHR 0,8 0t0 8 /dev/console (devfs) console-k 11619 root 12r VCHR 0,8 0t0 8 /dev/console (devfs) So in my case it actually opens /dev/console For reference, fstat -p: root console-kit-daemon 11619 12 /dev 8 crw------- console r This is indeed strange, because the code that tries /dev/tty gets executed before. It seems that ck_fd_is_a_console() returns -1 for /dev/tty in my case for some reason. What happen if you patch out the /dev/tty block forcing consolekit to use /dev/console?
(In reply to Gleb Popov from comment #11) That's a very interesting finding. Now things are less mysterious. Looking at vtterm_ioctl (I assume that we all use vt driver, not sc), CONS_GETVERS (used by ck_fd_is_a_console) should succeed for any terminal. So, I wonder if there could be some sort of a race. E.g., if the controlling terminal is revoked before CONS_GETVERS (or even before opening /dev/tty[*]) then the ioctl fails and the control flow proceeds to using /dev/console and everything is okay. But if /dev/tty is still valid when CONS_GETVERS is issued, then ConsolKit proceeds to using it, but then it gets revoked and things go bad. But I am conjecturing now. Need to do more experiments. To answer your question, I am sure that /dev/console would work the same or even better than /dev/ttyv0 that my patch currently forces. But I am going to test it for 100% confidence. [*] /dev/tty is implemented as a special "ctty" device, see sys/kern/tty_tty.c. If a process opening /dev/tty has a controlling terminal, then the opened device is actually a clone of that terminal device. If the process does not have a controlling terminal, then the cloned device is a clone of ctty special device and that device cannot be really opened.
Also, I am not quite sure how console-kit-daemon gets (normally) started. I see that it is running with --no-daemon option. So, it does not do its own daemonization and so it does not lose its controlling terminal by itself. It looks like it could be dbus that auto-starts console-kit-daemon using /usr/local/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service file. But system dbus daemon should run as a daemon itself. A bit puzzling.
(In reply to Andriy Gapon from comment #13) > It looks like it could be dbus that auto-starts console-kit-daemon You're correct and this is the intended way to start ConsoleKit. On my machines I use both SDDM and startx methods to launch a graphical session and these both methods rely on the D-Bus autoactivation feature. Regarding D-Bus daemon itself, I was pointed to ArchLinux, which starts it with --nofork option. I wonder if we should do the same and instead rely on our daemon(8) to daemonize it.
/dev/console seems to be a correct choice. If I read this code correctly [1], opening /dev/console results in opening something from the list of available consoles, which may contain ttyvX as well. Judging from the "conscontrol list" output, it seems that opening /dev/ttyv0 and /dev/console should give the same results. I have not yet figured out what's /dev/tty and what creates it, though. [1] https://github.com/freebsd/freebsd-src/blob/5682eee1efd35fb65751641181ae2a50d86efaab/sys/kern/tty.c#L2218
(In reply to Gleb Popov from comment #15) See my earlier comment 12, /dev/tty comes from tty_tty.c.
Re: comment 10 > … in bug 221452, in comment 39: … For convenience (auto-link): bug 221452 comment 39
(In reply to Andriy Gapon from comment #16) Ah, right, I read that part, didn't get anything and then forgot about it. Re-reading it now make things a bit clearer, but I do not understand what the "controlling terminal" is?
I've got some time for more experiments last weekend and I must admit that the basic premise of this bug report was false. I assumed that in my environment the console-kit daemon opened /dev/tty for some reason, but the assumption was wrong. console-kit-daemon actually opens /dev/console. And initially it works fine, but then somehow it gets broken. 3304 100948 console-kit-daemon 0.000021448 CALL openat(AT_FDCWD,0x207f70,0x8000<O_RDONLY|O_NOCTTY>) 3304 100948 console-kit-daemon -0.000131032 NAMI "/dev/tty" 3304 100948 console-kit-daemon 0.000059309 RET openat -1 errno 6 Device not configured 3304 100948 console-kit-daemon 0.000035080 CALL openat(AT_FDCWD,0x207f70,0x8000<O_RDONLY|O_NOCTTY>) 3304 100948 console-kit-daemon 0.000030242 NAMI "/dev/tty" 3304 100948 console-kit-daemon 0.000100756 RET openat -1 errno 6 Device not configured 3304 100948 console-kit-daemon 0.000129217 CALL openat(AT_FDCWD,0x20cc60,0x8000<O_RDONLY|O_NOCTTY>) 3304 100948 console-kit-daemon 0.000023367 NAMI "/dev/tty0" 3304 100948 console-kit-daemon -0.000070810 RET openat -1 errno 2 No such file or directory 3304 100948 console-kit-daemon -0.000327167 CALL openat(AT_FDCWD,0x20b782,0x8000<O_RDONLY|O_NOCTTY>) 3304 100948 console-kit-daemon -0.000032761 NAMI "/dev/console" 3304 100948 console-kit-daemon 0.000038416 RET openat 12/0xc 3304 100948 console-kit-daemon 0.000070820 CALL ioctl(0xc,CONS_GETVERS,0x8209b2934) 3304 100948 console-kit-daemon 0.000035115 RET ioctl 0 3304 100948 console-kit-daemon -0.000028165 CALL ioctl(0xc,TIOCGETA,0x8209b28e4) 3304 100948 console-kit-daemon 0.000091327 RET ioctl 0 3304 100948 console-kit-daemon 0.000029932 CALL ioctl(0xc,VT_GETACTIVE,0x8209b296c) 3304 100948 console-kit-daemon -0.000070518 RET ioctl 0 But after a while: 3304 101052 vt_thread_start -0.000074544 CALL ioctl(0xc,VT_WAITACTIVE,0x9) 3304 101052 vt_thread_start 0.000201533 RET ioctl -1 errno 25 Inappropriate ioctl for device Because console-kit-daemon keeps the descriptor open I was able to examine it and the corresponding vnode with kgdb. $1 = {f_flag = 1, f_count = 9, f_data = 0xfffff80002c27400, f_ops = 0xffffffff80f2d4b0 <devfs_ops_f>, f_vnode = 0xfffff8001e2ac8c0, f_cred = 0xfffff80298ee6100, f_type = 1, f_vnread_flags = 0, {f_seqcount = {0, 0}, f_pipegen = 0}, f_nextoff = {0, 0}, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0}, f_offset = 0} $2 = {v_type = VBAD, v_state = VSTATE_DEAD, v_irflag = 1, v_seqc = 1, v_nchash = 1355928945, v_hash = 1977032, v_op = 0xffffffff8127a5c8 <dead_vnodeops>, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfffff8001cd03e00, tqe_prev = 0xfffff8001ce2c028}, {v_mountedhere = 0x0, v_unpcb = 0x0, v_rdev = 0x0, v_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffff8001e2ac918}, v_cache_dd = 0x0, v_lock = {lock_object = {lo_name = 0xffffffff80d1cf3c "devfs", lo_flags = 116588544, lo_data = 0, lo_witness = 0x0}, lk_lock = 1, lk_exslpfail = 0, lk_pri = 64, lk_timo = 51}, v_interlock = {lock_object = {lo_name = 0xffffffff80db24c1 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, v_vnlock = 0xfffff8001e2ac930, v_vnodelist = {tqe_next = 0xfffff8001e494e00, tqe_prev = 0xfffff8001e33e0c0}, v_lazylist = {tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_lock = {lock_object = {lo_name = 0xffffffff80df4394 "bufobj interlock", lo_flags = 86179840, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, bo_ops = 0xffffffff812b7190 <buf_ops_bio>, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffff8001e2ac8c0, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffff8001e2ac9e8}, bv_root = {pt_root = 0x1}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffff8001e2aca08}, bv_root = {pt_root = 0x1}, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 4, bo_domain = 2, bo_bsize = 512}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffff8001e2aca50}, rl_currdep = 0x0}, v_holdcnt = 1, v_usecount = 2, v_iflag = 0, v_vflag = 10, v_mflag = 0, v_dbatchcpu = -1, v_writecount = 1, v_seqc_users = 1} The descriptor is open, the (devfs) vnode is in use, but it has been "recycled" and is no longer usable. It's hard for me to imagine what caused that. Perhaps, a revoke(2) system call -- but why would anything call it? -- or maybe some sort of devfs "re-mount". Anyways, since console-kit already uses /dev/console, my patch is most likely moot. There is something stranger going on. Maybe something specific to my environment.
I've noticed something going wrong with sddm/plasma6-kscreenlocker-6.3.3 lately: Mar 25 19:16:24 kev-ws-aurora kscreenlocker_greet[54012]: in _pam_exec(): pam_sm_setcred: pam_get_authtok(): authentication token not available in sddm.log: [21:18:04.831] (WW) HELPER: Failed to write utmpx: No such process [21:18:04.831] (WW) HELPER: Failed to write utmpx: No such process [21:18:04.862] (II) HELPER: [PAM] Ended. [21:18:04.862] (II) HELPER: [PAM] Ended. [21:18:04.939] (WW) DAEMON: Auth: sddm-helper exited with 15 Not sure if it is related to this. A `ck-unlock-session Session1` or sometimes a vt switch back and forth will recover.
(In reply to Kevin Bowling from comment #20) No, this sounds like another patch lost during the Plasma 5 -> 6 transition.
I checked it and all necessary patches are there. Unlocking via Plasma screenlocker also works for me. Anyways, this is not related to the problem being talked about in this PR.
(In reply to Andriy Gapon from comment #19) I finally was able to catch the culprit. This is what destroys the original /dev/console vnode. 1 15949 vgonel:entry 2025 Mar 25 21:45:33 vgone vnode fffff8000607b540, console rdev by sh (21) kernel`vgone+0x2f kernel`devfs_revoke+0x41 kernel`VOP_REVOKE_APV+0x71 kernel`killjobc+0x15a kernel`exit1+0x707 kernel`0xffffffff808bd00d kernel`amd64_syscall+0x189 kernel`0xffffffff80c4fbfb My understanding that this is exit of the rc shell process. init forks a process that exec-s the shell to run /etc/rc. The process sets up itself as a session leader and /dev/console as its controlling terminal (as well as stdin, stdout and stderr). It does that by calling login_tty() which internally uses setsid() and tcsetsid() to do the job. See runcom -> run_script -> execute_script -> open_console in sbin/init/init.c. I guess that this makes total sense give the nature of /etc/rc. When a session leader process exits, it revokes its controlling terminal. That's the standard behavior. I guess that the idea is that any descendant processes in the session get disassociated from the terminal. But in this case, the combination of those two sensible thing means revoking /dev/console from any process that opened it. Including daemons that independently opened it like what console-kit-daemon does. This also explains why the problem is racy. It depends on when a DM (such as lightdm for me) is started, how quickly it asks DBus to active ConsoleKit service versus how quickly the remaining rc scripts are completed. So, I things can vary greatly depending on hardware, installed and configured daemons, etc.
Given the info in comment #20, I now think that using /dev/ttyv0 as opposed to /dev/console may be a good idea for a couple of reasons. The primary reason is that /dev/ttyv0 wouldn't be revoked by /etc/rc exiting. Another reason is that /dev/console is not guaranteed to be associated with the video console (whether legacy or EFI). I think that it's possible to have a system with both video and serial consoles and configure it have serial console as the console while using video console for running X, etc. That wouldn't be a common configuration but still possible. On the other hand, if a system has video console then ttyv0 must always be there and it's on the video console. At least, that's my understanding.
TIOCCONS int *on If on points to a non-zero integer, redirect kernel console output (kernel printf's) to this terminal. If on points to a zero integer, redirect kernel console output back to the normal console. This is usually used on workstations to redirect kernel messages to a particular window. why isn't consolekit using this?
(In reply to Warner Losh from comment #25) Just to be clear: This is the ioctl that xterm has used since the 80s to connect a virtual terminal to the console. It gets back to what the ultimate goal here really is. I've not used consolekit so I don't know what it is trying to do. I've just used this feature back into the dim mists of time and wonder how it's different.
(In reply to Warner Losh from comment #26) Just in case, as we established in the arch@ thread, console-kit is not interest in the actual system console stuff like reading from or writing to it. It's interested in (a subset of) _video_ console ioctl-s defined in sys/sys/consio.h.
(In reply to Gleb Popov from comment #22) My bug was somehow related to 9c0e0196bdc6ddf75e801bda7f673ee2db645ad7 and the nvidia-driver using GSP firmware. With that disabled, it is functional as expected.
Should we now close this PR?
(In reply to Gleb Popov from comment #29) Not sure why... To me it seems that the conclusion was that - /dev/console is a wrong device to use for ConsoleKit's purposes; - we don't hae a perfect match for that role; - /dev/ttyv0 is the best we have. https://lists.freebsd.org/archives/freebsd-arch/2025-March/000904.html So, I am inclined to keep pushing for such a change. However, I do remember about bug 221452 where the opposite change was made. I cannot simply ignore that fact, but at the same time that change was "just stumbled upon". That is, nobody really explained why using /dev/ttyv0 caused the problem and how /dev/console fixed it. Unlike my in-depth analysis in this bug ;-) Please re-check comment 19 and comment 23. Also, I have been using my patch (with the opposite change) for many weeks now and I haven't seen any issues. On the contrary it has fixed the problems that I had. I am not sure how to proceed from here, but just closing this PR seems like a wrong move to me.
Just to be clear: I think the proposed patch is good. Console kit really wants that device, and it's the least bad thing we have, even in the face of a serial console.
(In reply to Andriy Gapon from comment #30) I've done some additional experimenting and I see why ttyv0 helped me, but was problematic for other other people. I have a small customization in /etc/ttys where I disabled getty on ttyv0. Just in case, my rationale for that is that I keep the first virtual terminal for kernel / console messages. It would be inconvenient to have a shell session there as any console messages would interfere with normal output. So, I just avoid having getting there. But I see that having a getty on ttyv0 can cause the same issue as init(8) caused for /dev/console. That is, revocation of the terminal device when the session leader on that terminal / virtual console terminated. E.g., if I log in on ttyv0 and the logout, I see this: 2025 Apr 29 20:32:16 vgone vnode fffff803fd074000, ttyv0 rdev by login (67940) kernel`vgone+0x2f kernel`devfs_revoke+0x41 kernel`VOP_REVOKE_APV+0x71 kernel`killjobc+0x15a kernel`exit1+0x707 kernel`0xffffffff808bd00d kernel`amd64_syscall+0x189 kernel`0xffffffff80c4fbfb So, ideally we do need a dedicated character device that could be used for issuing VT_ ioctls but which would/could not be used as a terminal for any program. Internally it could be aliased to ttyv0, all is needed is to have a separate devfs entry / vnode.
Another reason for having a special device node is an ability to wait for VT switching notifications using poll/kqueue rather than ioctl. Right now consolekit has to start a thread for each ttyv device present that all wait on ioctl (VT_WAITACTIVE)
Sorry, I had a feeling that I provided a positive feedback on this PR, but I was wrong. (In reply to Andriy Gapon from comment #30) > - /dev/console is a wrong device to use for ConsoleKit's purposes; > - we don't hae a perfect match for that role; > - /dev/ttyv0 is the best we have. This summarizes the problem very well, so I think we should merge your patch. Please don't forget PR: 285394 and also please add some short description of why this patch is needed in the header of the patchfile itself.
(In reply to Gleb Popov from comment #34) I am not sure myself now, though :-) Both /dev/console and /dev/ttyv0 (or any ttyvX) have their own sets of problems in this context. So, switching between then just switches from one problem to the other, from one set of complaining people to the other. E.g., we have this PR and bug 221452 asking for opposite things. I guess I'll try to find some time to work on a special character device that would be only for controlling video terminals but would not be associated with any terminal (idea from comment 32).
(In reply to Andriy Gapon from comment #35) Meanwhile, I started a grand project of writing login1 from scratch. I'll look into making the VT manager module resilient to revokes of the controlling device.
As a little update - I managed to make VT watching resilient to revoke()s in my daemon, but it is still far from being usable. Another data point is that opening /dev/ttyv0 requires root permissions for obvious reason and it is a blocker for rootless Xorg. OpenBSD folks use some other device, /dev/ttyC, which is probably a controlling-only device available for non-root.
I can confirm another manifestation of this problem on FreeBSD 16-CURRENT with consolekit2-2.0.0_2 and a dual serial/video console configured as follows: console="efi,comconsole" boot_multicons="YES" boot_serial="YES" The system reports both ttyu0 and ttyv0 as consoles, with serial as the primary console and video as the secondary console. The D-Bus-activated console-kit-daemon opens /dev/console. CONS_GETVERS succeeds, so ConsoleKit accepts that descriptor, but VT_GETACTIVE immediately fails with “Inappropriate ioctl for device.” ConsoleKit consequently records active VT 0. A local session on /dev/ttyv1 is added to seat0 but is never marked active. As a result, this command fails: ck-launch-session dbus-run-session kwin_wayland KWin reports that it cannot authenticate the DRM magic token, and DRM modesetting operations fail with Permission denied. Starting KWin through seatd-launch works. On the same system, VT_GETACTIVE fails on /dev/console, while /dev/ttyv0 correctly reports the active VT. Applying the proposed /dev/ttyv0 change fixes the problem. ConsoleKit then detects ttyv1 as active, emits SEAT_ACTIVE_SESSION_CHANGED, and KWin starts without the DRM permission failures. I built and tested the change against the current ports tree as consolekit2-2.0.0_3. I am aware of the separate concern discussed in comment 32: /dev/ttyv0 can itself be revoked when a login session on ttyv0 exits. Nevertheless, this test provides another concrete case where /dev/console is unsuitable, specifically when serial and video consoles are enabled together.