systems logs out when invoking shutdown ore reboot

[sunweaver]

Forwarding Debian bug #744264 [1] to upstream:

Package: mate-session-manager Version: 1.8.0-1 Severity: normal

Dear Maintainer,

Since I installed mate-session manager 1.8.1 it is impossible to shutdown or reboot the system as the only effect I have is a normal logout from the MATE session.

Also tried with the 1.8.0 package taken from the MATE repository and the problem is the same. Downgrading to version 1.6.0 (MATE repositories) solves the problem.

[1] http://bugs.debian.org/744264

[cddesja]

I can confirm this bug. It happens regardless of the desktop manager (i.e. I tried with both lightdm and gdm3). I am also on Debian Jessie.

[sunweaver]

Is your system using the classical SystemV startup system or is it already using systemd?

[EverEve]

Hello, I'm using SystemV and haven't tried with systemd yet.

[cddesja]

This bug goes away when using systemd. To fix it on Debian Jessie, apt-get install systemd-sysv worked here and I can now reboot/shutdown from the menu.

[EverEve]

Sorry, I don't think that this could be a solution - perhaps a workaround. I mean, as long as Debian allows its users to choose between SystemV, systemd and Upstart, I think that MATE should be usable with all these services managers

[cddesja]

This is largely irrelevant to me as I care about a working system and not the intricacies of service managers (systemd will be default in Debian). But to answer sunweaver's comment, with systemd this is not a problem.

[infirit]

MATE will support both consolekit and systemd/logind and both work properly for me. However it is not determined at runtime so you need to make sure at build time it is configured properly. [edit: I am not saying the build is wrong just explaining how it works!]

Now, we need to see the session log to see what is going on. The log is usually in ~/.xsession-errors [1] and it may hold useful info. Don't post them directly here but use a paste website to avoid this issue becoming unreadable ;-).

[1] in debian it may be a different file and I don't use debian.

[EverEve]

I have looked at the .xsession-errors file and it seemed to me that no related information was present. Then I even tried to recompile the package myself using the source from the MATE project (without the Debian patches) and the problem was the same.

@infirit is there any option I have to put at the end of the ./configure command to enable the consolekit support?

[Michael-AU]

I am getting this issue just recently, first noticed it last week, on my Haswell desktop with Wheezy and MATE 1.8. It does not occur at all on my laptop running wheezy and MATE 1.8. When I go to shutdown I just get a black screen with no way to get back to a login manager so I am forced to do a hard shutdown with the power button. ~/.xsession-errors clears at each new reboot. Next time this happens I'll run a Live session and see what is written in the file.

[raveit65]

see http://forums.mate-desktop.org/viewtopic.php?f=2&t=3019&p=8810#p8810 This is a well known issue with systemd-login which was occoured/fixed in fedora a year ago.

[EverEve]

@NiceandGently the problem doesn't seem to be the same as yours, as the command 'loginctl' gives me only one user logged and your workaround doesn't solve the issue.

@mantainers: can you please confirm the bug?

[Michael-AU]

Here's my xsession-errors http://pastebin.com/Lg9DpGLQ It appears as though something being installed but failed to install, only problem is I never attempted to install anything.

[diva4]

The issue is not visible, if the mate-session manager package is built under Debian Jessie without Systemd support, i.e. by adding the option "--without-systemd" to the override_dh_auto_configure options in file debian/rules.

[stefano-k]

This is the way how mate-session-manager check, at runtime, if systemd is running: http://git.mate-desktop.org/mate-session-manager/tree/mate-session/gsm-systemd.h#n42, as reported by systemd upstream. Could you check if, on Debian Jessie, do you have this folder also without systemd running?

[diva4]

In my Jessie system systemd-logind is active, but systemd-sysv is not installed. Therefore I have the folder "/run/systemd/seats/" I suspect that the original issue is related to logind and consolekit, but I don't understand how these packages interact.

[stefano-k]

@diva4 I agree that the issue is in systemd-logind without systemd

[monsta]

Happens for me too in Debian Testing with mate-session-manager 1.8.1-3.

~/.xsession-errors contains this line:

mate-session[8083]: WARNING: Unable to stop system: Launch helper exited with unknown return code 1

The directory /run/systemd/seats exists.

Installed systemd packages:

$ aptitude search ~isystemd i A libpam-systemd - system and service manager - PAM module i A libsystemd-daemon0 - systemd utility library i A libsystemd-id128-0 - systemd 128 bit ID utility library i A libsystemd-journal0 - systemd journal utility library i A libsystemd-login0 - systemd login utility library i A systemd - system and service manager

[EverEve]

Excuse me, is there any plan to solve this problem in Debian before systemd becomes the default init system?

Thanks.

[sunweaver]

Control: tag -1 moreinfo

Hi,

On So 06 Jul 2014 12:12:10 CEST, EverEve wrote:

Excuse me, is there any plan to solve this problem in Debian before
systemd becomes the default init system?

Thanks.

I have tested this issue now and don't see any problems when shutting
down or rebooting my Debian sid system from within MATE.

Please test again on some other hardware, try to narrow down the cause
of the observed problem.

Greets,

Mike

DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[monsta]

@sunweaver: you probably have systemd-sysv installed - the reports above say the issue isn't reproducible with it...

[sunweaver]

Well...

I have uninstalled systemd-sysv which installed systemd-shim and sysvinit-core.

And with that combination I just could successfully shutdown my system.

Can someone here give me exact instructions how to reproduce this issue with Debian jessie?

Thanks, Mike

[Michael-AU]

How about we concentrate on Wheezy which is supposed to be Debian Stable. I have a Wheezy machine using Debian's own repos and it wont shut down properly. I'll get more info later today.

[infirit]

Well, once you enable backports you are entering a less tested world.

Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!

[Michael-AU]

Ordinarily I would agree with you Infirit however the issue was most certainly alive and well when I was using MATE's own repositories. It started before MATE was integrated into Debian.

[monsta]

@sunweaver: I found out that Debian Testing repo update that came on 4th July pulled in the new version of systemd packages (204-14), and libpam-systemd now depends on systemd-sysv | systemd-shim. This means that if you uninstall systemd-sysv, systemd-shim will be installed automatically to satisfy this dependency.

Since you have Debian Unstable, you've already got this update earlier.

I only got this update today when I booted my Debian Testing VM after 3 or 4 days since the last boot. This update basically installed systemd-sysv and removed sysvinit-core, finally making systemd the default init system.

With systemd as the default init system, shutdown and reboot in MATE work properly now. So I can't reproduce the issue in Debian Testing anymore.

[stefano-k]

Can we close this issue?

[EverEve]

In my opinion this issue should not be closed. I mean, as long as Wheezy is the stable version of Debian, users would experience this bug.

But if you want to close it as "RESOLVED WONTFIX", I obviously cannot prevent you from doing that.

[stefano-k]

But bug on Wheezy is a distribution issue, not upstream one. It should be in http://bugs.debian.org/

[EverEve]

This very bug depends on the way the program mate-session-manager works. And I have opened it on Debian when MATE was not even in the Debian backports repository, and thus it was re-opened upstream.

So, if you do not want to solve it, you can simply say "I don't want to solve it". Fair enough.

[Michael-AU]

The bug in Wheezy was around well before MATE was incorporated into Debian let alone into Wheezy-backports. Sorry to say this but this bug is fairly and squarely a MATE issue not a Debian issue.

[stefano-k]

@EverEve I never said that we arent going to fix issues. MATE session was working well with both consolekit and systemd. Differently from other DEs, we are supporting both.

I just think the issue is not upstream because we are going to check if a folder is accessible to recognize if systemd is running, as suggested by systemd upstream developers.

#define LOGIND_RUNNING() (access("/run/systemd/seats/", F_OK) >= 0)

It seems on wheezy this folder exists, it is accessible, but for some reason systemd-logind is not answering to mate-session:

mate-session[8083]: WARNING: Unable to stop system: Launch helper exited with unknown return code 1

I think MATE Debian Maintainers can simply disable systemd support on Wheezy, and this issue will be solved.

[Michael-AU]

I'm not sure that's an accurate assumption. I have 2 machines running wheezy MATE. 1 (the one I am typing this on) shuts down properly the other (my i7 desktop) will not shut down using the normal shut down process. I'll get a package list to compare them later but the only systemd packages this machine has are libsystemd-daemon0 and libsystemd-login0.

[EverEve]

Ok but IN THE SAME CONDITIONS the package from the MATE 1.6 repository did work like a charm. Couldn't this be a useful hint?

Again: if I recompile the package without the systemd support, the program works. Couldn't this be another useful hint - for example I can figure out that the "systemd part" is "initialized" before the "consolekit part" (I am no coder, so I'm just guessing). And without the systemd support, the other works correctly.

[infirit]

I have a wheezy vm from a few weeks [1] ago which does not have this problem at all. It does not have /run/systemd/seats/. It looks like the problem is the existence of this directpry.

[1] A net install with only MATE installed as desktop and no other software.

[monsta]

Guys, there are two systemd versions in Wheezy: the ancient 44-11 in the main repo and 204-8 in the backports. Since you've installed MATE from the backports anyway, I think it makes sense to get systemd from there too. I'm asking just in case - to eliminate one possible source of the problems.

[Michael-AU]

On my i7 Wheezy MATE install now to check it. systemd packages are the exact same as my laptop (which works fine). Neither machine has /run/systemd folder so the problem has absolutely nothing to do with this directory in Wheezy (it may in Jessie but not in Wheezy).

Just trying monsta's suggestion with regards to backport systemd packages. Will reboot and test after another reboot (so 2 reboots in order to make sure).

[sunweaver]

Hi All,

I run several Debian systems (wheezy + MATE from wheezy-backports) and I did not have any reboot/shutdown issues ever.

/me scratches his head and wonders what issues people here bump into...

Mike

[monsta]

@sunweaver: do you have systemd from the backports too? Also - is it set as the default init system (with systemd-sysv installed) on your Wheezy machines?

[stefano-k]

@sunweaver however, given that Wheezy comes without working systemd, and that consolekit is available (also if users will install systemd from backports, consolekit is working), I suggest to build mate-session-manager there with --without-systemd

[stefano-k]

Just a link to understand shutdown procedure with systemd enabled: http://git.mate-desktop.org/mate-session-manager/tree/mate-session/gsm-manager.c#n480

[Michael-AU]

monsta's suggestion made no difference. Tomorrow I will remove the 2 systemd packages (if it will let me) from my faulty wheezy install and see if that makes a difference.

[monsta]

@k3lt01: looks like shutdown/reboot is working properly only if systemd is installed and is the default init system. In my Debian Testing, when I had several systemd packages installed (see the full list at https://github.com/mate-desktop/mate-session-manager/issues/53#issuecomment-47338412) but the init system was still sysvinit, shutdown/reboot didn't work. When the dist-upgrade pulled in systemd-sysv, the issue disappeared.

[Michael-AU]

@monsta at this moment it seems as though installing systemd-sysv is not an option because I am getting warnings that installing it removes other Essential components and doing so may render my system unusable. If it was my laptop that had the problem I'd jump in and give it a go but this machine (my i7) is my main machine and I can't afford for it to crash.

I am doing an apt-get dist-upgrade now, systemd-sysv was not one of the packages listed so it is not being installed, will test to see if it helps.

Trying to remove the already installed systemd packages pulls up a list of things that will be removed and MATE is one of them, libsystemd-daemon0 and libsystemd-login0 appear to be dependencies of MATE in wheezy-backports and I am assuming it was (simply because this problem is pre Debian integration) in MATE's own repository packages as well.

[Michael-AU]

No difference at all after dist-upgrade in wheezy.

[monsta]

libsystemd-daemon0 and libsystemd-login0 appear to be dependencies of MATE in wheezy-backports

This might explain why LOGIND_RUNNING() succeeds while systemd-sysv isn't there - and so the shutdown/reboot doesn't work. I guess this check for a directory is not enough for the proper systemd detection.

[stefano-k]

@k3lt01 do you have mate-session-manager 1.8.1-4~bpo70+1 ?

[stefano-k]

@monsta https://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00092.html

[monsta]

@stefano-k: there's an interesting check from Lennart himself, mentioned at the bottom of the post:

As check whether systemd was actually booted: access("/run/systemd/system/", F_OK) >= 0

Indeed, this directory is present in the current Debian Testing - but not present in e.g. LMDE where systemd is installed but not set as the default init system yet.

Maybe use it as an additional check?

[Michael-AU]

@stefano-k, my laptop has mate-session-manager 1.8.1-2~bpo70+1 although synaptic tells me that there is an update for it. I will check my i7 desktop later tonight. Will update the laptop now and the desktop later if required and report back if that changes anything.

[monsta]

@k3lt01: libsystemd-login0 contains only a library. /lib/systemd/systemd-logind executable itself is in systemd package.