Summary: | x11/lightdm-gtk-greeter: Crashes when run with daemon login class | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Daniel O'Connor <darius> | ||||
Component: | Individual Port(s) | Assignee: | Ben Woods <woodsb02> | ||||
Status: | Closed Overcome By Events | ||||||
Severity: | Affects Only Me | CC: | darius, madpilot, woodsb02 | ||||
Priority: | --- | Flags: | woodsb02:
maintainer-feedback+
|
||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Daniel O'Connor
2019-11-21 04:32:49 UTC
Actually I couldn't attach it, I have hosted it at http://www.gsoft.com.au/~doconnor/kdump.txt.bz2 This looks like a bug I thought I fixed. The problem could be lightDM requiring locked memory, and the daemon class limits that to 128MB by default, which is not enough. Please check that you have this in /usr/local/etc/lightdm/lightdm.conf: [LightDM] lock-memory=false If it still fails maybe the daemon is ignoring that config. You can make it work anyway by modifying /etc/login.conf and setting the locked memory limit for daemon to 256 MB and restarting lightdm (don't forget to run cap_mkdb /etc/login.conf). Hope this helps. Unfortunately lock-memory=false is already there so I guess it must be a different issue. (In reply to darius from comment #3) > Unfortunately lock-memory=false is already there so I guess it must be a different issue. Have you anyway tried to increment the locked memory limit in login.conf? It's worth a test anyway. Good idea, I should have done that! It does work if I increase the locked memory limit for daemon (and remove my mod). Perhaps the greeter is trying to lock memory too (and the config directive is for lightdm itself)? Darius suggested on IRC that maybe it's lightdm-gtk-greeter locking memory, and he's correct. in light-gtk-greeter sources at src/lightdm-gtk-greeter.c line 2752: /* Prevent memory from being swapped out, as we are dealing with passwords */ mlockall (MCL_CURRENT | MCL_FUTURE); This is unconditional, we can simply comment it out or implement a configuration directive or something. woodsb02 what do you think? Created attachment 209703 [details]
Proposed patch
I'm proposing this simple patch.
It comments out the mlockall(2) system call, stopping the greeter from locking all its memory.
This is the correct solution IMHO, there is no point in locking all the memory a GUI program uses.
Ben what you think about this?
Can you please check if the most recent updated to the x11/lightdm port (new package version is lightdm-1.30.0_2) has fixed the problem for you? Essentially I was getting reports of a different issue, and the problem turned out to be the lightdm user needed access to the video group in order to use the graphics drivers. https://svnweb.freebsd.org/changeset/ports/523696 I don't need to add lightdm to the video group, but perhaps it is required for other video drivers (I am using nvidia) For my case it only seems to be the locked memory issue. Hi darius and madpilot, As it turns out, the upstream lightdm-gtk-greeter developers have recently disabled mlockall, and this change is included in the 2.0.7 release. This has been committed to the ports head branch in r526738: http://svnweb.freebsd.org/changeset/ports/526738 Can you please test and confirm it is fixed? I will close this bug in the meantime. Regards, Ben Comment on attachment 209703 [details]
Proposed patch
This patch is correct, but it is no longer needed since it has been incorporated upstream.
|