| Summary: | 2_b1: Running startx from text login does not register a new session. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bit Twister <bittwister2> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, mageia |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | xinit-1.3.2-1.mga2.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
getfacl results
systemd-loginctl, ck-list-sessions and getfacl count |
||
|
Description
Bit Twister
2012-02-23 07:42:42 CET
Shouldn't be needed. Please attach the output of "getfacl /dev/snd/*". CC:
(none) =>
davidwhodgins Created attachment 1620 [details]
getfacl results
Colin what is needed for having sound in the init 3 ? CC:
(none) =>
mageia Can you check what systemd-loginctl outputs? You should be registered as a session on multi-user.target (it is for me). Not sure what happens when you run startx, but I'm guessing it's maybe doing something strange with console-kit, so with that in mind can you provide: 1. Boot to multi-user.target (aka runlevel 3) 2. Login to getty. 3. Get output from systemd-loginctl and ck-list-sessions 4. Check getfacl /dev/snd/* (just confirm or not whether your user is listed in the ACLs) 5. startx 6. Get output from systemd-loginctl and ck-list-sessions again. 7. Check getfacl /dev/snd/* again. Status:
NEW =>
ASSIGNED Created attachment 1652 [details]
systemd-loginctl, ck-list-sessions and getfacl count
Oh and one more thing: After startx: udevadm info --query=env -n /dev/snd/pcm* It should have a line: TAGS=:uaccess: (I strongly suspect it will not) I believe the problem is that the xinit package contains no systemd-logind-xinit-session binary (it currently contains source to build a console-kit version of this). No such binary exists and thus it needs to be written. Source RPM:
(none) =>
xinit-1.3.2-1.mga2.src.rpm (actually it might contain that tag... it just won't apply it due to it not detecting the current session as the current and active one). (In reply to comment #7) > (actually it might contain that tag... $ udevadm info --query=env -n /dev/snd/pcm* DEVNAME=/dev/snd/pcmC0D0c DEVPATH=/devices/pci0000:00/0000:00:14.5/sound/card0/pcmC0D0c MAJOR=116 MINOR=4 SUBSYSTEM=sound TAGS=:uaccess: UDEV_LOG=3 USEC_INITIALIZED=14497221 > it just won't apply it due to it not detecting the current session as the > current and active one). I'll agree with that. OK, so this is basically something that other distros are phasing out and no longer supporting. Essentially doing proper session management (something that systemd does) is more or less orthogonal to the idea of startx. The problem is that you have an existing session and you are trying to create a new one from that. It could ultimately be supported, however I suspect it will take too much engineering work to do that (we would have to create a setuid wrapper that spoke to pam and then logged your user in with a new session after starting x). Here is the upstream explanation (Lennart describes the problem much better than me): http://lists.freedesktop.org/archives/systemd-devel/2012-February/004614.html So I suspect that this will sadly have to be a WONTFIX for mga2... of course if someone wants to work on the utility needed (either by hacking gdm or writing something independent) then I'd be more than willing to look into it :) Status:
ASSIGNED =>
RESOLVED |