My case may be a limited niche but I've been doing it 20+ years so I don';t really want to change my ways if it is at all possible.

I boot to Runlevel 3. There, I login as root, do whatever deeper level work I desire. and then call on a DisplayManager/LoginChooser to get into X. With KDM there was a menuitem for "Console Login" that returned me to the exact original root login and a simple "killall kdm" dumped me fully out of X which is essential for most deep level work even like installing updates or an nvidia driver.

Now, with SDDM, at least launched as root, nothing, not even init 3 as some recommended, will kill all of X. I have to reboot. Additionally, and this may be related, logging in initially as root apparently defeats the ability to use default sddm.conf setting "MinimumVt=7" so I have to Alt-F7 or, better for my normal usage, edit to "MinimumVt=1".

All I want to do is to be able to login runlevel 3 as root and easily return there if and when needed. Can sddm be configured to accommodate my ways. Incidentally, I'm pretty sure the auto-switch to F7 is not being defeated by the graphics driver since it works with other systems, even LiveSlak, although LiveSlak boots to runlevel 4. If that's all there is to my obstacle I could probably give up logging in at CLI if that meant I could get there easily and without rebooting.

You make it sound to me like Slack works very differently than Debian, Fedora, Mageia, openSUSE and others in getting a DM up and running. On all my installations, I can boot without a DM (RL3 equivalent) and login on any or all available ttys, root or otherwise, and switch on "RL5" without killing any existing sessions. Thus, any can be used to kill the DM, as long as keyboard works to make a switch, or remote login is available.

On openSUSE, KDM3 is still available unemasculated by "advances" in technology. It's what I'm using here. There's also TDM, forked a decade ago from KDE3, with binaries available for quite a few distros.

What did change since systemd took over is that an X session opened without a DM will run on the same vtty started from instead of 7 or whatever minimumVT was configured for the distro. Fedora likes putting X on 1, which I find highly annoying. I like leaving 1 as it was after init completed, full of plain text boot messages, unless I've exhausted all others.

Thanks for responding mrmazda but I'm not sure it deals with my issue since afaik there is no "RL3 equivalent" in those distros you mentions as there is no entry in inittab or whatever systemd calls it these days. I'm not doubting whatever you are referring to is similar but "service<name> service" calls don't work on Slackware and even if it did systemd has it's own names for devices.

I can login to any VT from initial runlevel 3 or after Alt-F<number> after having launched SDDM as root. My problem is that after initial root logs in and sddm doesn't stop for "Logout" (it's essentially just "restart x" just like "Ctrl-Alt-Backspace") I can no longer stop the initial root login or drop back to runlevel 3. Issuing "init 3" from an X terminal does nothing. I can't seem to stop SDDM without rebooting. KDM had a "Consoile Login" button (Ctrl-N by keystroke macro iirc) that would drop one back to RL3 but still required a call, "killall kdm" to complete the process and stop all X. That button and that macro are no longer used by SDDM, afaik.

I suspect if I booted directly into runlevel 4, which launches sddm by default, I could leave sddm.conf MinimumVt=7 stock default and it would autoswitch from Vt=1 and then "init 3" would work as it does for others. I would simply prefer to boot to runlevel 3 as root and be able to "go back" on demand. I've got an install of Trinity DE and a few older versions of Slackware where KDM is still used but I don't wish to go back to kdm (it was a pita to find the .conf edit as little as I needed it) and SDDM is more efficient, it just lacks one basic action I've grown accustomed to.

Thanks anyway for trying

Note: It has been a long time since I previewed the distros you mentioned but as I recall even last year's Debian prefers users not even have an actual root account, leaving all such (allowed) work to "sudo". From my POV those practices and systemd have severely limited my distro testing. I very much dislike the "lowest common denominator" choices most other distros make that attempt to turn MY PC into a "loaner" instead of an "owner".

Hi,

I tried doing what you have explained (if I understood it correctly) in a VM: booted the system and entered runlevel 3. Then I logged in as root in tty1. After logging in, I started SDDM by typing the command:
After running that command, SDDM started at tty7 and I got switched automatically to tty7. At this point, I could stop SDDM either by switching back to tty1 (Ctrl+Alt+F1) and then just press Ctrl+c in the keyboard, or I login to other tty as root and then I run
Either approach seemed able to kill SDDM and I could continue to use the root login at tty1 as usual. Note that I used "sddm.bin" since the main SDDM process is actually invoked with that name, where "sddm" is just a wrapper shell script that started "sddm.bin" at the end of that script. Since the script doesn't use "exec" when invoking "sddm.bin", the shell script is actually still running thus when you run "killall sddm" you just kill this script, not SDDM itself, and SDDM will keep on running until you run "killall sddm.bin". Perhaps "sddm.bin" should be renamed back to "sddm" and then put to other place like /usr/libexec. This way, "killall sddm" will also kill the main SDDM process even though the wrapper script doesn't use "exec" to start SDDM, avoiding confusion. Still, using "exec" in the wrapper script when starting SDDM is a good idea to do (IMHO) since we don't need that shell program running in the background anymore when SDDM has started. It just unnecessarily eats resources in the background.
Doing this will not do anything since you are already in runlevel 3 (running SDDM through the root prompt at tty1 doesn't count as switching to runlevel 4, you have to run "init 4" to switch to runlevel 4, which in turn will start SDDM automatically as configured in /etc/inittab).

Thanks for your response mumahendras3, and I will try that again since I updated to the most recent Current/Vtown. Until today I was running Current from 11/29/2020 and it seems some important entries are changed.

This morning I tried my suspicions and setup inittab to default to runlevel 4 to see if behaviour matched others and it pretty much does. I hit a minor snag that only worried me for being unusual but the SDDM background had changed and when I tried to put it back to a snapshot I prefer I found that SDDM no longer accepts simple jpgs or pngs as bacjground but wants a damned zipped up Theme file... and I don't see the value in such a trivial change but whatever I guess.

Anyway, I finally added "auto user login" just to spit in SDDM's face and to see if I didn't hate it. It is substantially faster but given it's only a short time testing, I still prefer my old, if slower way. So today I'll try that again encouraged by your experience if a little hesitant using VM experience to apply to "real world" behaviour, but your explanation of sddm.bin is very encouraging.

Systemd distros I'm familiar with all have init/telinit symlinks to systemd calls. Runlevel 3 equates as much as it can, since it works so very much differently, to multi-user.target, while runlevel 5 (no distro I'm familiar with ever used runlevel 4; in them, the display manager was launched via runlevel 5) translates to graphical.target. Thus, init 3 while "5" is active will quit the display manager, without disturbing any logins on ttys 1-6 (in my Debians, my openSUSEs and all my Mageias) or those on 2-? (those that run the DM on tty1).

I can't imagine no one can do with Slack what we did before systemd with other distros and do now with systemd. Whether starting X automatically during init, whether in runlevel 5 or in graphical.target, we had and have a bunch of ttys for logins, and a DM running on tty1 or tty7 or tty8. Any login on a tty can be used to drop back to runlevel 3 or multi-user.target, killing the DM, whether GDM, KDM, LightDM, SDDM, TDM, XDM or ..., and any running X session(s) in the process, all without disturbing any logins on any of the ttys. It works the other way too, a bunch of logins on ttys if started in runlevel 3 or multi-user.target, and when X is wanted, either use startx to skip the DM, or switch to runlevel 5 or graphical target from a tty login command that starts the DM.

SDDM lacks all kinds of goodies KDM provided. That's why I use KDM3 or TDM. With KDM I find kdmrc, and symlink its kdm homedir to /etc/kde/kdm, to find kdmrc where it should have been in the first place. With TDM, it's already /etc/trinity/tdm/tdmrc.

AFAICT, genuine Debian made no such change. All my Debian installations have normal root accounts. Ubuntu and Mint and I suppose other derivatives default to the sudo paradigm. That default is easy to ignore:

Hello again, mrmazda. I'm not certain but I think that once there exists a root login, as when booting to runlevel 3 in Slackware, logging in a 2nd time as root is not allowed to "trump" the first login and initiate a shutdown. Why it won't allow that from the initial root login once in X, I really don't know but I have verified that my installation works this way.

If I setup /etc/inittab to a runlevel 4 default, which means it launches SDDM with no account login let alone root, issuing the command "init 3" from a terminal as root or User in X will initiate dropping back to runlevel 3 which then asks for login credentials. I even played with adding to this by setting an autologin by User to Plasma 5 and it operates the same way but impressively fast especially on an SSD install. Despite all that and though I will leave one install operating the latter way complete with to determine if I can live with that arrangement, I'm setting my Main back to a runlevel 3 default and going back to root login, although I may play with employing User login and "startx", "startxfce4", "startfluxbox", etc.

Unless I learn further that there is a workaround for equal rights root logins, I will try killing "sddm.bin" now that I understand that "sddm" is a script and all it's components, especially the main executable do not stop with "killall sddm". If that works out as I am confidant it will, I can mark this thread solved.

Thank you for your posts and it is probably because I still try out a few other distros each year that I am mixing up Debian with probably PopOS which does thwart a root account, being more like a 2nd Gen Debian derivative, al la 'Buntus, but afaik neither Debian nor PopOS, or many Debian derivatives any longer allow the use of kdesu and certainly don't want anyone launching say Dolphin as root. All of them afaik do not allow a root login to any WM/DE. I can't live with that.

SOLVED - well... at least functionally though it does take a few more steps. I have to "ps aux | grep sddm" to get sddm.bin PID and kill that but it works. An odd note is that if I then reissue a "sddm" command it bypasses the Login/Greeter step and goes right back to a full Plasma Desktop. Curious, and kinda cool. Bottom line is I can work with this since it isn't everyday that I need to drop back to runlevel 3. Even though autologin is a LOT faster, I will likely not convert since once (which is looking like rather soon) the Official New Slackware Release hits the streets, I will remove my old 14.2 and my newer testing installs of various levels of Current, and settle on one Main, one passive backup and two partitions for testing other distros. Merry Christmas!

Postscript: I forgot to mention that although I will keep a 32 bit 14.2 system installed (thanks to CSM even on a Z490) LiveSlak on a USB drive has gotten SO GOOD with massive persistence that I no longer need redundant systems for fast recovery when playing around "in flight" results in crash and burn

Once again, many thanks and well wishes to Eric (Alien Bob).

As a side note I recently learnt
With -a to get the process name in addition. Much benefits (but that might be because of the franchement kb layout).