Home | News | Download | Packages | Forum | Wiki | Github

Slim DM won't work


#1

Here’s a gist with my enabled services, my ~/.xinitrc and my /etc/slim.conf.
I’ve tried both the default settings (which let you cycle through available sessions by pressing F1) and a config where sessiondir is hashed out in /etc/slim.conf and ~/.xinitrc execs it’s first argument (as written here), and in both scenarios the same thing happened:
My PC booted up and switched to tty7 which had slim open. I typed in my username and password, slim tries to launch xorg but it exits so slim just returns. I tried getting some more info (don’t remember how, I’ll check in a minute) and it seemed like it has something to do with the DISPLAY variable.
Did this happen to anyone else?

EDIT: I somehow got it to work by reenabling slim, IDK how I didn’t try it before. But for some reason some programs in my ~/.xinitrc don’t get executed (specifically wal, but when I open a terminal and execute the very same command from my .xinitrc it works. Is there any chance that it’s not a wal bug?


#2

Slim’s latest release is from 2013 and it’s no longer supported.
You can still use it, but I woundn’t.
Actually, I don’t use a display manager at all.


#3

@omrisim210

Slim login starts lxde on my glibc amd64 system after edit of /etc/pam.d/slim

 #%PAM-1.0

 auth        include     system-local-login
 #-auth       optional    pam_gnome_keyring.so
 account     include     system-local-login
 session     include     system-local-login
 #-session    optional    pam_gnome_keyring.so auto_start

(garry) #4

Thanks cardinal maybe that will help me – on my last install I chose the musl variant of Void amd64, hoping to reproduce the working environment that I have on OpenBSD (cwm window manager, occasionally switching to gnome 3.24 or xmonad). It disappointed me to find that slim could not initiate a session and gdm segfaulted. (sddm and lxdm work ok on the musl system). [EDIT] On a clean install of Void/musl slim works just perfectly!

pin may have the best advice; it may be time to stop struggling with slim. I even had to abandon it on OpenBSD where it now aborts its startup if it is enabled in rc.conf but can be successfully started from the command line. I found that a nice approach is to use xdm and let my ~/.xinitrc start cwm. cwm supports easy switching to any other window manager or DE. xdm is rock solid reliable. (I use a display manager so that no user is normally logged in on a console and when I put my computer to sleep it is impossible to resume operation, in the gui or in a console, without entering a password). Using startx leaves the computer physically insecure against an intruder, even if you do use a screen locker to lock the gui when away from the office.

[EDIT] I installed the glibc variant of void, alongside my musl void, and installed slim with a .xinitrc much like the OP. Slim ran fine and logged me into my fluxbox session. (and slim looks quite nice with the slim-void-theme). The only differences I see from what he did was (1) I don’t start consolekit from /var/service, just dbus – I let slim handle consolekit, and (2) I don’t use ck-launch session in my .xinitrc, just
exec dbus-launch --sh-syntax --exit-with-session “$1”


(Xlaits Xavier) #5

Why not use LXDE’s LXDM?


#6

@sitquietly

Using startx leaves the computer physically insecure against an intruder

How?
I usually login from the console using my password.
If I login as root, I will be using console only for system administration tasks. No DE or WM under root.
If I login as user, I’m brought to my fluxbox environment. If I then exit fluxbox, I’m back at the console and have to enter a password for root or user in order to do anything.
startx is executed from the user .bash_profile


(garry) #7

If I understand you boot your computer and then login to the console. There, from the command line on tty1, you execute xinit (or startx).

Doesn’t xinit fork your gui session? There are then two ttys running login processes. (1) the forked tty, perhaps on tty8, and (2) the original tty, presumably tty1. Let’s say you use xlock to lock your gui and then walk away from your computer to go shopping. While you are away anyone who walks up to your computer finds that they can’t do anything because it is demanding a password, but they can Control-Alt-F1 to get into your login shell on tty1, logged in and not requiring any password. They could then do anything that you could do, such as erase all of your files. I know there are other solutions to this problem but one is to login from xdm and not leave any consoles open. Control-Alt-Fn only switches to pseudo-terminals that are each demanding a password.


(Xlaits Xavier) #8

Instead of assuming, why not try it out?


(garry) #9

Excuse me. I failed to respond to what you actually wrote. Your technique is indeed one of the “other solutions” to using a display manager, and it can be a good alternative. For others to follow I’ll link to a wiki entry describing the technique of auto-startx upon logging into tty1.


(Masato the Empty) #10

I personally don’t care for launching X from a logged-in VT, but if that’s your thing, there are usually multiple ways to get around what one might see as disadvantages.

So if you’ve got an issue with having an unlocked VT on your desktop even if you lock the X screen (even an unprivileged user account should can be a security concern), then see this thread as it discusses just that.


#11

@xlaits
Thanks!
@sitquietly
Hope that it helps. But, actually it was oliver that helped me with this. See the following Void with fluxbox

@masato
I don’t care either. :slight_smile: