You are not logged in.
This probably something to do with my trying out different display/window managers.
AMD Phenom II X6 1100T 3.3GHz Black Edition (Socket AM3)
Gigabyte 990XA-UD3 AMD 990X (AM3+) DDR3 PCI-Express ATX
Alpine Ezcool Midi Black EC-7103H (ATX/PIV)
8GB Mushkin Blackline LV #996988 (2x4GB) DDR3
1TB Western Digital Caviar Black WD1002FAEX 3.5" SATA III Hard Drive
LiteOn DVD +- RW
Gainward GeForce 9500GT 1GB PCI-Express 2.0
3.10.5-1-ARCH #1 SMP PREEMPT Mon Aug 5 08:04:22 CEST 2013 x86_64 GNU/Linux
KDM
KDE4.10.5
Here are the symptoms:
Running systemctl reboot from a terminal in KDE immediately reboots
Reboot from the KDE menu stops at Reached target graphical display (the reboot command is set to "systemctl reboot")
Removing the .kde4 directory and allowing KDE to recreate the default settings makes no difference
Obviously I have done something stupid, but I cannot think what.
Please help
Andrew
Offline
No ideas?
The error message in journalctl is 'KDM: Failed to execute shutdown command "systemctl poweroff"'
Could do with some help here.
Andrew
Offline
If you start kde with startx instead of KDM, does this problem persist (yuo may have to set up an .xinitrc, as I am not sure how KDM works)?
Also, what happens if you issue systemctl poweroff from the command line? And while we're at it, how about trying to shutdown/reboot the system from KDM itself? If the journal is reporting that the request is being kicked down to KDM, maybe debugging from there might be worthwhile.
Does KDM register itself as active with logind? If it doesn't then that would explain why KDM is unable to shut down the machine.
Offline
Hello WonderWoofy, seems that you are always the one to help me out - thanks
I disabled the display manager in systemd (KDM) and rebooted to a login prompt. Startx ran KDE, but then reboot and shutdown from KDE did not work, only Logout.
Running systemctl poweroff from the command line works faultlessly, but does not close KDE correctly e.g. does not save the session.
Shutdown or Reboot from KDM, i.e. the menu options in KDE, both fail at "Reached target graphical interface"
KDM appears to be registered with logind:
$ loginctl list-sessions
SESSION UID USER SEAT
1 501 andrew seat01 sessions listed.
Cheers
Andrew
Offline
It sounds like you are not getting an active session when you are using startx. The session has to run under the same tty as it was started from in order for logind to continue tracking it. This is handled by a proper xserverrc. Check out the /etc/skel directory and there is a proper xserverrc file there. It *should* be used automatically even from that directory. But you might want to copy it to your $HOME, just to ensure that it is being used.
To check to make sure your session is active, do loginctl as you have already above. Then use that session number to get the info you need with loginctl show-session <session #>. Look for the line that says "Active". If it says "no", then you need to fix that in order for the shutdown, reboot, suspend and hubernate functions to work properly from a normal (non-root) user.
So get that working first before you try to test thse things mentioned in my previous post.
Offline
If it says "no", then you need to fix that
Clearly you have it:
$ loginctl
SESSION UID USER SEAT
1 501 andrew seat0
1 sessions listed.
[andrew@ezcool ~]$ loginctl show-session 1
Id=1
Timestamp=Wed 2013-08-14 16:07:03 CEST
TimestampMonotonic=34093992
DefaultControlGroup=systemd:/user/501.user/1.session
VTNr=1
TTY=tty1
Remote=no
Service=login
Leader=463
Audit=1
Type=tty
Class=user
Active=no
State=online
KillProcesses=no
IdleHint=yes
IdleSinceHint=1376489232334662
IdleSinceHintMonotonic=43126790
Name=andrew
Can you point me in the right direction or fixing it?
Many thanks
Andrew
Offline
Just copy the /etc/skel/.xserverrc to you $HOME and then try using startx again. This should ensure that the X session stays on the same TTY as it was started from, thereby allowing logind to track the session properly.
If you already have a ~/.xserverrc file, then you need to either back it up and then move this one from /etc/skel into place, or you need to simply overwrite it with the one in /etc/skel.
Edit: Upon further investigation, I found that no package actually owns my /etc/skel/.xserverrc. So you can find the one that the system is supposed to use in /etc/X11/xinit. This is where the system will fall back to in the event that the xinitrc and/or xserverrc are not present in your home directory.
Last edited by WonderWoofy (2013-08-14 17:20:53)
Offline
If you start kde with startx instead of KDM, does this problem persist (yuo may have to set up an .xinitrc, as I am not sure how KDM works)?
If you do not start KDE from KDM, there is often a problem using shutdown/poweroff etc. from KDE's menu. I'm not sure if this problem still applies since I use KDM and have never experienced the problem.
Does KDM register itself as active with logind? If it doesn't then that would explain why KDM is unable to shut down the machine.
Yes. That is, it should.
EDIT: On second thoughts, I'm not clear that this is a login-tracking or authorisation issue at all. If the session were not active in loginctl, systemctl reboot should also fail from the command line, shouldn't it? Moreover, wouldn't it do nothing as opposed to starting shutdown and then stopping? Why is it reaching graphical.target at all when shutting down?
In addition to WonderWoofy's suggestions, do you have any .pacsave/.pacnew files in /usr/share/config/kdm? Have you modified kdmrc at all? In particular what do
grep HaltCmd /usr/share/config/kdm/kdmrc
grep RebootCmd /usr/share/config/kdm/kdmrc
give?
Last edited by cfr (2013-08-15 01:10:26)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
If it says "no", then you need to fix that
Clearly you have it:
$ loginctl SESSION UID USER SEAT 1 501 andrew seat0 1 sessions listed. [andrew@ezcool ~]$ loginctl show-session 1 Id=1 Timestamp=Wed 2013-08-14 16:07:03 CEST TimestampMonotonic=34093992 DefaultControlGroup=systemd:/user/501.user/1.session VTNr=1 TTY=tty1 Remote=no Service=login Leader=463 Audit=1 Type=tty Class=user Active=no State=online KillProcesses=no IdleHint=yes IdleSinceHint=1376489232334662 IdleSinceHintMonotonic=43126790 Name=andrew
This is not initiated by kdm/kde, though, is it? You need to look at the output after logging into kde from kdm if you want to troubleshoot sessions started that way.
Or have I misunderstood your goal here?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Right, thanks for the help.
I think that the reason that loginctl said "Active=no" was that I logged in from a command line using startx. Logging in with systemd display manager set to KDM shows "Active=yes".
I will check the .pacsave/.pacnew files issue as soon as I can.
Many thanks
Andrew
Offline
I think that the reason that loginctl said "Active=no" was that I logged in from a command line using startx. Logging in with systemd display manager set to KDM shows "Active=yes".
No. The reason you are not getting an active session when using startx is because your X session is not starting on the same TTY as your are logged into. I tried to explain this before...
Offline
Sorry, I misunderstood.
However with KDM I am getting Active=yes, so still looking.
Andrew
Offline
Can we see the output of loginctl and loginctl show-session <session-id> when you are logged via KDM? Also the output of the grep I mentioned above.
Have you examined kdm.log and/or the output of journalctl? That should hopefully give some sort of clue.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Sorry for the delay, I have been on the road
$ grep HaltCmd /usr/share/config/kdm/kdmrc
HaltCmd=systemctl poweroff
$ grep RebootCmd /usr/share/config/kdm/kdmrc
RebootCmd=systemctl reboot
$ loginctl
SESSION UID USER SEAT
1 501 andrew seat0
1 sessions listed.
$ loginctl show-session 1
Id=1
Timestamp=Fri 2013-08-23 09:43:20 CEST
TimestampMonotonic=34069259
DefaultControlGroup=systemd:/user/501.user/1.session
VTNr=7
Display=:0
Remote=no
Service=kde-np
Leader=509
Audit=1
Type=x11
Class=user
Active=yes
State=active
KillProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=andrew
Cheers
Andrew
Offline
I notice 2 things. The first is that you are using kde-np rather than kde. The second is that you have systemd:/user/501.user/1.session where I have systemd:/user/1000.user/1.session.
I don't know if these are significant. On my system user ids start at 1000. However, I don't think this probably matters - I think those are just the default values used by useradd etc.
Can you confirm that you obtained the output above after logging in through kdm? i.e. not using startx or running a startup command directly? If so, I think the question may be why you have kde-np. I don't know what the difference is but the initials are surely suggestive.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
501 is the default first user of OSX. When I used to dual boot my Macbook with Linux, I would always make my UID's 501 to match my OSX UID. I never had any trouble with this. When I realized I never ever used OSX, which was coincidentally about the same time I switched to Arch, I just wiped it from my HDD and started using the default 1000.
I'm not sure if this is why the OP chose 501, but I would bet that it had something to do with file access across a dual boot scenario.
Offline
Yes. I think the kde-np thing is more likely a clue than the uid. It was just something I noticed. Now I check, you are right. I was 501 on OS X. I must have chowned everything when I moved to Arch. Or Debian. I can't remember what I did in Debian but I think I only had read access to HFS+...
/etc/pam.d/kde-np
#%PAM-1.0
auth required pam_tally.so onerr=succeed file=/var/log/faillog
auth required pam_shells.so
auth requisite pam_nologin.so
auth required pam_env.so
auth optional pam_permit.so
account include system-login
password include system-login
session include system-login
/etc/pam.d/kde
#%PAM-1.0
auth include system-login
account include system-login
password include system-login
session include system-login
Last edited by cfr (2013-08-24 00:58:54)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Sorry for this additional OT post, but @cfr, I think that i too just used ro access from OSX, as I wasn't willing to turn off journaling to use hfsprogs, so I forced the writability, disregarding the warnings… sure enough the filesystem got corrupted to shit. So after reinstalling, I use the paragon extfs to at least give myself ext4 write access from OSX.
Offline
I am not sure that I followed all that
I use 501 as my user id for historic reasons. I have three computers all with the same id and it would be a pain to change them all.
I have no idea what the difference between kde and kde-np is. My laptop has the same result and shuts down perfectly.
It is definitely a kdm problem, since I can log in as a different user on the same machine, and it still does not close down properly. Swapping to lightdm not only closes down correctly, but a lot quicker.
Still I would like to know how I have fouled up kdm.
Reinstalling kdm looks like a pain, since it is part of kdebase-workspace
Thanks for all the help
Andrew
Offline
You are using passwordless login to kdm? That's what the np stands for, it seems.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I do use auto-login, which may be the same thing. It does not seem to be the problem though.
Andrew
Offline
Maybe you should post kdmrc and check there are no .pacnew or .pacsave versions with relevant changes. (I don't remember anything relevant recently, though.)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
There are no .pacnew or .pacsave on my system
kdmrc:
[General]
ConfigVersion=2.4
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
GreeterUID=kdm
PidFile=/var/run/kdm.pid
ReserveServers=:1,:2,:3
ServerVTs=-7
StaticServers=:0
[Shutdown]
BootManager=None
HaltCmd=systemctl poweroff
RebootCmd=systemctl reboot
[X-*-Core]
AllowNullPasswd=false
AllowRootLogin=false
AllowShutdown=Root
AutoReLogin=true
ClientLogFile=.xsession-errors-%d
Reset=/usr/share/config/kdm/Xreset
Session=/usr/share/config/kdm/Xsession
SessionsDirs=/usr/share/config/kdm/sessions,/usr/share/apps/kdm/sessions
Setup=/usr/share/config/kdm/Xsetup
Startup=/usr/share/config/kdm/Xstartup
[X-*-Greeter]
AntiAliasing=false
BackgroundCfg=/usr/share/config/kdm/backgroundrc
ColorScheme=
FaceSource=AdminOnly
FailFont=Sans Serif,10,-1,5,75,0,0,0,0,0
ForgingSeed=1346867137
GUIStyle=
GreetFont=Serif,20,-1,5,50,0,0,0,0,0
GreetString=Welcome to %s at %n
GreeterPos=50,50
HiddenUsers=
Language=en_GB
LogoArea=Logo
LogoPixmap=
MaxShowUID=65000
MinShowUID=500
Preloader=/usr/bin/preloadkde
SelectedUsers=
ShowUsers=NotHidden
SortUsers=true
StdFont=Sans Serif,10,-1,5,50,0,0,0,0,0
Theme=/usr/share/apps/kdm/themes/elarun
UseBackground=true
UseTheme=true
UserCompletion=false
UserList=true
[X-:*-Core]
AllowNullPasswd=true
AllowShutdown=All
NoPassEnable=false
NoPassUsers=
ServerArgsLocal=-nolisten tcp
ServerCmd=/usr/bin/X
[X-:*-Greeter]
AllowClose=false
DefaultUser=andrew
FocusPasswd=true
LoginMode=DefaultLocal
PreselectUser=Previous
[X-:0-Core]
AutoLoginEnable=true
AutoLoginLocked=false
AutoLoginUser=andrew
ClientLogFile=.xsession-errors
[Xdmcp]
Enable=false
Willing=/usr/share/config/kdm/Xwilling
Xaccess=/usr/share/config/kdm/Xaccess
Thanks
Andrew
Offline
See https://bugzilla.redhat.com/show_bug.cgi?id=699114.
This is an old bug which has been fixed. However, it is the only thing I can find with the error message you are finding. Moreover, it looks like there are some useful diagnostic strategies you can run here to get more information about what is preventing shutdown. You may need to update it a bit, of course. (E.g. the halt command you have in kdmrc is definitely correct already.)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
So far, no joy.
The link above was interesting, but, as you say, does not seem to relate to my problem. I still have a login prompt at Reached Target Graphical Interface.
I have tried removing the kdm configuration files, /usr/share/config/kdm, and reinstalling kdebase-workspace. No change except for losing all the settings for kdm. I previously tried removing .kde4 and letting kde recreate it.
For the present I have switched to lightdm, which works fine.
Andrew
Offline