In the past, we'd go to init 3 to run smxi tools. While that may not be 100% necessary in all cases, I've recently noticed, with newer kernels, that for some reason, when you boot up to init 3, no visible console displays appear. Equally disturbing, if you boot to the graphical mode, init 5, then run smxi and shut down X and Slim, once you finish, Slim does not want to start up, claiming that it's already running, yet it's unavailable. Because of this, several times, with both antiX and Debian Sid, I've had to reboot, when I really did not want to do so.
Does anyone know, first, what is causing this scenario to happen, and second, what to do to resolve it? Seems to me that there have been changes in the way that the non-graphical consoles work, and I have not yet figured out how to get them running in the manner that I am used to, and therefore, I would be interested in tips and suggestions on how to access the console in non-graphical init levels. Thanks!
6 posts
• Page 1 of 1
-
masinickPosts: 1,139
- Joined: 26 Apr 2008
-
tradetaxfreePosts: 75
- Joined: 18 Jan 2012
#2
When I update Xorg or video drivers:
CTRL ALT F1 & login as a user
Then:
CTRL ALT F1 & login as a user
Then:
Code: Select all
sudo /etc/init.d/lightdm stop #or slim
#do stuff
sudo /etc/init.d/lightdm start #or slim-
masinickPosts: 1,139
- Joined: 26 Apr 2008
#3
@ tradetaxfree: My issue, on some Debian-based systems, is that if I boot into anything other than graphical user interface mode at init 5, then go back to init 3 to run a console, I cannot visibly see a console. I have a feeling this has something to do with the console-kit-daemon processes that now run. I don't know what they do, but at least to me, they are a huge overhead, and unless you know what to do with them, they make it more difficult (not easier) to run a console shell outside of a graphical user interface.
My guess, but it's just a guess, is that some process that pertains to these console-kit-daemons, needs to run for whatever init level in which you want to run a console (which, to me, is stupid; consoles, at least if you have defined them in your tty definitions), should exist by DEFAULT. That's NOT what I'm getting any more. If I boot to S, single user, I see nothing. If I boot to init 3, I see nothing. But if I boot to init 5, then go BACK to init S or init 3, THEN I can see a console. That is NOT what I want to do. I want to be able to perform routine console operations at any time in any init level without having to go through some special process, so I'd really like to better understand what these console daemons (that have only started to appear within the past year, and have only been a problem in the last 3-6 months or so)... what they're all about, why they are even needed, and what happens if you don't have them. Any knowledge on this or links to somewhere I can read up? My searches so far have netted nothing, so I'm not using the right keyword searches yet.
My guess, but it's just a guess, is that some process that pertains to these console-kit-daemons, needs to run for whatever init level in which you want to run a console (which, to me, is stupid; consoles, at least if you have defined them in your tty definitions), should exist by DEFAULT. That's NOT what I'm getting any more. If I boot to S, single user, I see nothing. If I boot to init 3, I see nothing. But if I boot to init 5, then go BACK to init S or init 3, THEN I can see a console. That is NOT what I want to do. I want to be able to perform routine console operations at any time in any init level without having to go through some special process, so I'd really like to better understand what these console daemons (that have only started to appear within the past year, and have only been a problem in the last 3-6 months or so)... what they're all about, why they are even needed, and what happens if you don't have them. Any knowledge on this or links to somewhere I can read up? My searches so far have netted nothing, so I'm not using the right keyword searches yet.
-
tradetaxfreePosts: 75
- Joined: 18 Jan 2012
#4
console-kit-daemon does not seem to be much overhead on my system:
If you only need the console to run smxi stopping the Display Manager as shown above does the trick. Restarting the DM takes me straight back to my desktop without having to log in again.
Code: Select all
ps wwu -C console-kit-daemon
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 4255 0.0 0.1 29152 2508 ? Sl 02:25 0:00 /usr/sbin/console-kit-daemon --no-daemon-
lucky9Posts: 26
- Joined: 13 Jul 2008
#5
Anybody ever find anything on this?
-
masinickPosts: 1,139
- Joined: 26 Apr 2008
#6
Nope. but I talked to Harold Hope, the author of the smxi tool, about this, and he said that graphical drivers are notorious for causing problems, and it did not surprise him at all to see this kind of behavior. I, personally, however, blame the behavior on these console kit daemons. Once upon a time (and I have NO IDEA why they had to change this) we just had very simple getty drivers that were nothing more than simple serial console drivers. They could handle TTY devices (TTY devices actually date clear back to those really slow, noisy, telegraph devices you'd hear in news rooms and press rooms, and the OLD Western Electric used to make many of those early teletypewriters, and that's what TTY stands for). Well, with CRT (that's an old one, too: Cathode Ray Tube) and LED (Light Emitting Diode) display devices, they were originally driven by TTY drivers, but someone, in their wisdom, turned these into"console kit daemons" instead of TTY drivers, and it has been since the advent of these processes (there are a ton of them, and they don't work half as well as the old device drivers), that is when my problems began. I don't know who or what to report it to, but I'm going to do some research and see if there is a console kit daemon that I can file a bug report against, maybe to the Debian release team for Wheezy, if I can find it...