32-bit boot.iso, a Gnome only install results in a situation where when you attempt to do a restart, or power off, you are prompted to enter the Administrator Authentication password. After typing the Admin Password the restart, or power off, process proceeds normally. No such thing occurs with a KDE install.
Oh my...if you let it sit long enough at the log in screen the need for Admin Authentication goes away. How long it has to sit? More then a few minutes anyway. Crazy. I'll keep poke'n at this thing.
CC: (none) => olav
Can't reproduce this. - click on the user name at the right of the top panel - press ALT and the "Standby" option changes to "Shutdown" - click on the option and you will see the usual box with "Cancel - Reboot - Shutdown". No admin password necessary (if I did not misunderstand what you are talking about)
CC: (none) => molch.b
Here's the methodology that I used to recreate this problem. 1. A totally new today, and up-to-date, install of Mageia 2, Gnome 3 only. 2. Reboot to login screen, login to Gnome 3 3. Click on the (User)... icon in upper right hand corner of desktop 4. Vertical menu bar presented does not give a restart or shutdown choice ( Now I'm Really Really gonna throw a wrench into this thing ) 5. Execute the next steps in 60 seconds or less 6. Clicking on Logout... choice takes you to a window in the middle of the desktop giving you 60 seconds to change your mind. Clicking on the "Log Out" button takes you back to login screen. 7. Click on the Icon in the upper right hand corner of Log in screen ( circle with stick in it ). That gives you three choices. They are: Suspend Restart Power Off 8. Quickly execute one of the following two steps: 9. If you select "Restart" you are immediately presented with a request for Admin Authentication. Typing the Admin PW the system will reboot the system normally. 10. If you select "Power Off" you are immediately presented with a request for Admin Authentication. Typing the Admin PW the system will power off the system normally. 11. Warning!!!! If you select the "Cancel" button thing in 9 or 10 ( within the 60 seconds ) really bad things can happen including a system freeze. If when you get back into the login screen from Gnome 3 you wait 60 seconds or more the system will reboot, or power off, normally without the need for the Admin Authentication. I love it when I find stuff like this. It makes my day.
Ok, let's see, I installed Beta3 Gnome yesterday, did all the updates, nothing more. (Comments using your points) 4. So you did not press the ALT key here to change the last option in the vertical menu bar into "Shutdown"? 6. Done 7. Done 9. Done - system immediately restarts, no password request. 10. Done - system immediately shuts down, no password request.
Oh My! Thanks Wolfgang. More testing is needed on this one by me. I'll try this on several different computers here in the next days.
Maybe you did different settings in msec (i.e. higher security level) which may forbid $USER to shutdown? Just a wild idea...
(In reply to comment #6) > Maybe you did different settings in msec (i.e. higher security level) which may > forbid $USER to shutdown? Just a wild idea... I agree, lots of things to look at on this one. If this is really a problem we don't want it to get out in the wild. It appears to me to be a timing problem ( fast computer vs slow computer? ). I'll keep poke'n at it.
(In reply to comment #7) > It appears to me to be a > timing problem ( fast computer vs slow computer? ). No, I don't think so. It worked ok on 3 different "classes" here: rather slow netbook, Core2Duo laptop, and on my i7 desktop machine.
I'm not sure if this is related or not, but I use GDM with a KDE desktop, and when I select Leave -> Reboot from the KDE app launcher and click on the timer prompt to continue, it exits to GDM, and then I get a GDM prompt saying that administrative authority is needed. However, IIRC, if I just logout from KDE and then initiate reboot from the GDM login panel, there is no password prompt.
CC: (none) => ftg
(In reply to comment #9) > I'm not sure if this is related or not.... Many thanks for your input. My thoughts are that there is definitely something going on here. Probably not anything related to KDE or Gnome, just something running ( a timer maybe ) that gets out of whack somehow. Keep poking and logging your experiences here.
I've shot a video of this process. You can view that video on YouTube at: http://www.youtube.com/watch?v=J-SxWv4-njg Maybe someone can see something I'm doing wrong here or recognize the authentication page from somewhere. The video is only 51 seconds long.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
(In reply to comment #11) > I've shot a video of this process. You can > view that video on YouTube at: > > http://www.youtube.com/watch?v=J-SxWv4-njg > > Maybe someone can see something I'm doing > wrong here or recognize the authentication > page from somewhere. The video is only 51 > seconds long. No, that is exactly what I find using GNOME Classic. Switching to kdm removes the fault but it returns on switching back to gdm.
CC: (none) => tarazed25
*** Bug 6429 has been marked as a duplicate of this bug. ***
CC: (none) => guillomovitch
Keywords: NEEDINFO => (none)CC: (none) => mageiaSource RPM: (none) => gdm
guys, are you using autologin ?
Manuel Hiebel said in Comment 15: > guys, are you using autologin ? This morning I executed a complete new install of Mageia 3 ( Cauldron ) using 32-bit boot.iso ( 21 Oct 12 ) using my local mirror ( mirrored to kernel.org ). That was a Gnome only install and was successful. After booting to a working Gnome desktop I did the following: Upper right hand corner User pull down select Logout Logout in 60 secs ( over ride ) Log in screen Upper Right hand corner pull down Select restart System asks for Admin PW this is regardless if the boot is set to Autolog in or not. Same problem occurs both ways. MCC -> Install & Remove Software Select and install task-kde Once I switch over to KDE, autologin or not, then a restart does not require an Admin PW to power down or reboot.
arf so my idea was wrong :s (because I have never seen that personally beside lives install)
(In reply to comment #16) > > This morning I executed a complete new install of Mageia 3 ( Cauldron ) using > 32-bit boot.iso ( 21 Oct 12 ) using my local mirror ( mirrored to kernel.org ). > That was a Gnome only install and was successful. Last night I did exactly the same (except for the mirror, I used ftp.mandrivauser.de which sync'd with distrib-coffee 45 minutes before installation). Followed the steps as described by Will, result confirmed. According to how this situation is seen by the Gnome developers and what is written on the authorization screen this is not a bug but a feature: Rebooting "while other users are logged in" needs system admin power.
Following up on Wolfgangs Comment 18 Then if that's the way the Gnome folks want it to be then let it be. I'll change the status of this to RESOLVED.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Oops! I'm not saying that I know that Gnome folks think like that. But in the light of that "explaining" sentence about other users logged in it looks logical.
I'm not convinced this is "expected behaviour" in this context. It's due to the fact that the session of the user logging out is not finished. e.g. some of their processes are lingering around and thus gdm is not considering the session to be finished. There has been various discussions upstream about this, and how to deal with sessions that are "closing" but not yet closed etc. so I think this behaviour will be resolved such that permission will not be needed if other user sessions exist but are closing. Might need to apply a couple patches from upstream bugs to resolve this fully. I could of course still be wrong on that. I will chat to a few guys upstream about it.
Well, we could both be right on that :) Not closed processes are run by various users (I mean system users, even root, not real persons), so all processes that will be closed by "shutdown" can cause this behavior. I suggest for this "bug" to be put on hold, waiting for upstream decision/fix.
(In reply to comment #22) > Well, we could both be right on that :) > Not closed processes are run by various users (I mean system users, even root, > not real persons), so all processes that will be closed by "shutdown" can cause > this behavior. Not really. Lots of processes are run by other users but this doesn't mean they are being run inside a user session and thus trigger any of the logic discussed above. loginctl will show you all the user sessions and with appropriate arguments the processes in question and the "state" of the session (whether it is open, closing, closed etc and whether it is active or inactive). Typically this would only include real users, either locally or via ssh etc. In a typical user session, some processes linger around. e.g. PulseAudio will stick around until it's idle timeout is reached. gpg-agent and similar will also keep running and keep the session alive (albeit in a "closing" state). As mentioned previously I think there have been various discussions about this (can't find the bugs/mailing list comments right now) so I think the idea is to ignore "closing" sessions when dealing with decision making process.