[SOLVED] Simple way to logout ALL USERS remotely?

damgar · 12-26-2009, 09:41 PM

This might be the wrong forum, but it seemed like it might get the proper exposure here. Please excuse me if I was wrong.

I am trying to find a command that will simply logout all users and close all sessions on a machine with a single command or at least as simply as possible.

I am playing with remote access to one of my machines and in the proccess I have frequently wound up with multiple sessions on the target machine from the same user (root, I know, I know), thus sucking resources which is counter productive to what I'm trying to accomplish with the remote logins. Is there a simple way to log EVERYONE out so that I can just log back in after all those resources should, in theory at least, be released?

bartonski · 12-26-2009, 10:30 PM

I think that this should work, but test it before you run it in a production environment.

Code:

ps aux | egrep '(tty|pts)' | awk '{print $2}' | kill

You may want to add 'grep -v root' to the pipe line before the awk expression.

damgar · 12-26-2009, 11:10 PM

Thanks for the response. The command didn't work (it gave errors about "kill usage" and proccesses that didn't exist which is weird), but it taught me enough to find one that would work and that was 99% of the solution.

WARNING IF ANYONE TRIES THIS: NO DATA WILL BE SAVED AND THIS IS INSTANT.

The command I found that worked was:

PHP Code:



kill `ps -ef | egrep '(tty|pts)'`

It's extreme but effective!

bartonski · 12-27-2009, 12:34 AM

Quote:

Originally Posted by damgar

Thanks for the response. The command didn't work (it gave errors about "kill usage" and proccesses that didn't exist which is weird)

oops, that should have been

Code:

ps aux | egrep '(tty|pts)' | awk '{print $2}' | xargs kill

I composed the first part of the command, using 'echo' instead of 'kill' (so that I wouldn't actually log myself out), then got it slightly wrong when I pasted it in.

I'm still looking at the command that you gave

Code:

kill `ps -ef | egrep '(tty|pts)'`

I'm slightly disturbed by this. If I replace 'kill' with 'echo':

Code:

$ echo $(ps -ef | egrep '(tty|pts)')
root 956 1 0 Dec26 tty4 00:00:00 /sbin/getty -8 38400 tty4 root 959 1 0 Dec26 tty5 00:00:00 /sbin/getty -8 38400 tty5 root 965 1 0 Dec26 tty2 00:00:00 /sbin/getty -8 38400 tty2 root 966 1 0 Dec26 tty3 00:00:00 /sbin/getty -8 38400 tty3 root 968 1 0 Dec26 tty6 00:00:00 /sbin/getty -8 38400 tty6 root 1270 1265 1 Dec26 tty7 00:15:33 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-rr5xDx/database -nolisten tcp vt7 root 1815 1 0 Dec26 tty1 00:00:00 /sbin/getty -8 38400 tty1 tiger 11052 11050 0 Dec26 pts/0 00:00:00 bash tiger 24032 11052 0 01:10 pts/0 00:00:00 bash tiger 24033 24032 0 01:10 pts/0 00:00:00 ps -ef

What's happening is that everything emitted by "ps -ef | egrep '(tty|pts)'" is being used as an argument to 'kill'. This includes a lot of extraneous stuff, such as the process owner, the time the process was spawned, which tty it was spawned from... which should be relatively harmless, as well as the process ID of the login process that you're trying to kill... but then it also includes the process ID of the parent process. In several cases, this is the PID of init (which is '1'). Killing init will take your whole system down, and fast... and even if you don't have permissions to kill init, you probably don't want to kill the other parent processes.

This is why I included the 'awk' statement, which specified only the PIDs of the processes that I wanted to kill.

As an aside, there are also a few stylistic issues with that line: back-ticks are generally deprecated in favor of '$()', and piping arguments to xargs is always better than feeding arguments through command substitution.

damgar · 12-27-2009, 01:00 AM

It seems that the same pid's will be returned by either command?

Quote:

root@dtest:~# ps -ef | egrep '(tty|pts)'
root 3182 1 0 Dec26 tty6 00:00:00 /sbin/agetty 38400 tty6 linux
root 3193 3191 0 Dec26 tty7 00:00:00 /usr/bin/X -br -novtswitch -quiet -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-NU4OE6
root 5271 5269 0 00:50 pts/2 00:00:00 /bin/bash -l
root 5287 5271 0 00:50 pts/2 00:00:00 ps -ef
root 5288 5271 0 00:50 pts/2 00:00:00 egrep (tty|pts)

I took this output to all be related to user-logins. In this case my current login which should be the only one on the machine........I think. What I do know is that it returned me to the kdmchooser which then allowed me to log back in and went from 5.5 of 6 gigs of ram being used to .5 which is all I was really after since what I'm actually doing is to use the power and speed of the Slack machine while a few things like amarok continue to run on the local machine. It's actually faster to do it this way than to be local to either machine alone.

I would definitely be interested in a cleaner way to do this, it seems like there would HAVE to be. The part about having to do it remotely is the hardest part it seems, because the machine has to be immediately available for remote logins or it does me no good. I would never consider my method for a production environment, or if there were useful processes running on the remote machine. (I'm just trying to let my sick wife get some rest! lol).

bartonski · 12-27-2009, 10:51 AM

actually, the format is a little different:

Code:

$ ps aux | egrep '(tty|pts)' 
root      1054  0.0  0.0   1700   544 tty4     Ss+  11:14   0:00 /sbin/getty -8 38400 tty4
root      1056  0.0  0.0   1700   548 tty5     Ss+  11:14   0:00 /sbin/getty -8 38400 tty5
root      1062  0.0  0.0   1700   548 tty2     Ss+  11:14   0:00 /sbin/getty -8 38400 tty2
root      1063  0.0  0.0   1700   544 tty3     Ss+  11:14   0:00 /sbin/getty -8 38400 tty3
root      1065  0.0  0.0   1700   548 tty6     Ss+  11:14   0:00 /sbin/getty -8 38400 tty6
root      1348  1.6  0.5  42828 21532 tty7     Ss+  11:14   0:21 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-Wl6r03/database -nolisten tcp vt7
root      1842  0.0  0.0   1700   540 tty1     Ss+  11:14   0:00 /sbin/getty -8 38400 tty1
tiger     2488  0.0  0.0   4848  2080 pts/0    Ss   11:35   0:00 bash
tiger     2495  0.0  0.0   2640  1016 pts/0    R+   11:36   0:00 ps aux
tiger     2496  0.0  0.0   3036   816 pts/0    R+   11:36   0:00 egrep (tty|pts)

The awk command has the magic though, it cuts out the second column:

Code:

$ ps aux | egrep '(tty|pts)' | awk '{print $2}'
1054
1056
1062
1063
1065
1348
1842
2488
2553
2554
2555

This is exactly the PIDs that you'd like to kill, and no more.

damgar · 12-27-2009, 11:57 AM

Quote:

The awk command has the magic though, it cuts out the second column:

Definitely more elegant.

Quote:

As an aside, there are also a few stylistic issues with that line: back-ticks are generally deprecated in favor of '$()', and piping arguments to xargs is always better than feeding arguments through command substitution.

I've heard this before. What is the reasoning for this, as backticks sure are easier to type! As a here-to-now-point-and-clicker I definitely have an affinity for things that don't requier SHIFT+TOP_ROW_KEYS! The command I gave was actually my first forray into any extended command option/piping.

bartonski · 12-27-2009, 07:21 PM

Quote:

Originally Posted by damgar

I've heard this before. What is the reasoning for this, as backticks sure are easier to type! As a here-to-now-point-and-clicker I definitely have an affinity for things that don't requier SHIFT+TOP_ROW_KEYS! The command I gave was actually my first forray into any extended command option/piping.

1) Backticks are hard to read... it's often hard to tell them apart from single quotes, which is a significant difference.

2) Backticks don't nest well.