For a few months I've been having a little problem with smxi which I can't overcome. Not important but niggling.

If I drop from KDE into tty1 via CTRL + ALT + F1, login as root, run smxi and then restart X via menu option 8, everything functions as it should except that using a command like gksu /usr/sbin/synaptic fails.

When logging out of KDE the "Abort active sessions" dialog appears reporting that tty1 login session is still active and this appears to be the core of the problem.

Unless I'm being really dumb (more than likely) there appears to be no way of aborting this session from KDE. So is it possible for smxi to abort the login session when it exits via menu option 8?
Back to top

smxi should be killing the session, maybe it needs to check at other exit points, but most users are exiting to do something then, so obviously you don't want to exit the session there.

Please be specific, where are you exiting? it's probably somewhere I just wouldn't think people would exit, or forgot to handle it.
Back to top

TechAdmin:

I usually use smxi to do my daily dist-upgrade. Once the upgrade finishes I select option 4 (continue) from the menu and then select option 8 (start x) from the ensuing menu. That's all I do.

The thought occurs to me that the function to stop X and enter runlevel 3 isn't working correctly. I say this because I use smxi in a diferent way from most people. I gather from the forum that most people use smxi at boot after entering entering run level 3 or 1 via the grub command line. Whereas I am in tty1 at run level 5 with X running when I run smxi.

The difference between the 2 methods is that I rely on smxi (via menu option 1) to stop X and enter the correct run level whereas most people are already at run level 3 with no X when they run smxi.

To test this idea I did CTRL + ALT + F1, init 3 and then ran smxi in order to mimic the method other people use. After returning to the desktop via menu option 8, viola, a command like gksu /usr/sbin/synaptic now works as it should. So it would seem that the smxi function to exit X and enter run level 5 isn't working properly.

smxi log extracts:

after the above test:-

START smxi LOGGING:
=========================================================
Script started: 2010-02-20-11:12:18
Installed Kernel: 2.6.32-8.slh.3-sidux-amd64
smxi script version: 8.11.31
smxi start args:
=========================================================
Function: check_display_and_x - Primary: Start
Function: get_display_manager_runlevels - Utility: Start
Function: get_default_display_manager - Utility: Start
displayManager: kdm
Function: get_default_display_manager - Utility: End
dmRunlevels: 5
Function: get_display_manager_runlevels - Utility: End
5
Function: do_display_manager_pid_test - Utility: Start
Function: x_is_running - Utility: Start
returnVal: 1
Function: x_is_running - Utility: End
found:
Function: do_display_manager_pid_test - Utility: End
Function: create_script_files - Primary: Start


When I rely on smxi to stop X and go to run level 3

=========================================================
START smxi LOGGING:
=========================================================
Script started: 2010-02-20-01:50:02
Installed Kernel: 2.6.32-8.slh.2-sidux-amd64
smxi script version: 8.11.30
smxi start args:
=========================================================
Function: check_display_and_x - Primary: Start
Function: get_display_manager_runlevels - Utility: Start
Function: get_default_display_manager - Utility: Start
displayManager: kdm
Function: get_default_display_manager - Utility: End
dmRunlevels: 5
Function: get_display_manager_runlevels - Utility: End
5
Function: do_display_manager_pid_test - Utility: Start
Function: x_is_running - Utility: Start
returnVal: 0
Function: x_is_running - Utility: End
found: true
Function: do_display_manager_pid_test - Utility: End
Function: check_display_and_x - Primary: End
opt selected: shutdown-desktop-and-continue
Function: start_stop_default_dm - Utility: Start
Args: full stop
Function: get_default_display_manager - Utility: Start
displayManager: kdm
Function: get_default_display_manager - Utility: End
Function: x_is_running - Utility: Start
returnVal: 1
Function: x_is_running - Utility: End
Function: start_stop_default_dm - Utility: End
Function: do_display_manager_pid_test - Utility: Start
Function: x_is_running - Utility: Start
returnVal: 1
Function: x_is_running - Utility: End
found:
Function: do_display_manager_pid_test - Utility: End
Function: create_script_files - Primary: Start

I hope this is of some use and I am glad to do any future tests you may require.
Back to top

I see a couple of things that may contribute to your problem. First when you drop to tty1(ctl+alt+f1) there should be no need to init3. Just log in as root and run smxi.
Second, you mention that your using kde, shouldn't you be using kdesu instead of gksu? gksu is usually based in gtk type environments.
One last thing, "daily" dist-upgrade usually isn't a good idea(if you run sid), once or twice a month is better.
Back to top

orbit, you aren't using smxi in a different way than most people, this is how it's intended to run. The init 3 strart is just an easy way to boot to console, that only works in sidux and other distros that use the 3 / 5 (actually it can be 2,3, or 4, it really doesn't matter. Debian uses only 2 for everything.

The init 3 stuff is something that sidux told people to do, it doesn't matter at all, smxi doesn't care what init level it runs in, you can just do: cntrl alt f1 then let smxi kill x and restart x.

However, you are right, when you do not use the sgfxi mechanism to start the desktop, it ooes not check for your default run level and try to start it, sgfxi does, but smxi doesn't, that functionality can be restored.
Back to top

TechAdmin:
Thanks for your explanation and and hopefullly the restoration.

eriefisher:
Thank you for your comments but if you read my first post you'll see that doing what you suggest is a contributory cause of the problem. Also using either gksu or kdesu makes no difference as their functionality is virtually the same.
Back to top

sorry, it's been a long time since I looked at this, the method is intact and should be working.

I'm going to assume either your system changed from default or the defaults changed.

Show this:

make sure to copy that to avoid typos.

then, with kdm stopped, in runlevel 5, do:


then return to console with ctrl alt f1 and see what the output says.
Back to top

orbit, sorry, I misread your posting, you are right, there was a bug in the login pid detection which caused the session kill to fail in some but apparently not all cases, that bug has been there a LONG time, but for some reason it worked anyway, at least I thought it was working in my test systems, I don't understand why or how though it could have been.

I have fixed that bug in smxi and sgfxi, and now the active session should be terminated, thanks for the update.

I got sidetracked by the init 3/5 issue, which is not related, and which is I assume in fact working fine.

Thanks for the bug report, I believe that was a real one.
Back to top

TechAdmin:

Only too glad to be of some use.

Thank you.
Back to top