Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to terminate a login session from a shell script?

0 views
Skip to first unread message

Henry Zhaohuiliu

unread,
Jan 20, 1999, 3:00:00 AM1/20/99
to
Hello,

We tried to terminate a login process from a shell script that is
directly logout from the script. The 'exit' command only quit from
the script to command line, not directly logout from current
login session.

I was suggested to use kill -9 -1, it works, but if you use it as a root,
then it may kill all the processes.

I also tried kill -9 $$, it can kill the current login session if you use
it in command line. But if you use it in a script, it just terminate the
script and quit to command line.

Thank a lot!

Henry


Dan Mercer

unread,
Jan 20, 1999, 3:00:00 AM1/20/99
to
In article <785kj2$4$1...@netnews.upenn.edu>,

Try:

logout:
#!/usr/bin/ksh
kill -s hup -$$


if that doesn't work, try:

#!/usr/bin/ksh
kill -s hup -$PPID

Dan Mercer

dame...@uswest.net

Opinions expressed herein are my own and may not represent those of my employer.


Robert Butram

unread,
Jan 20, 1999, 3:00:00 AM1/20/99
to
I set up multiple sub-office UNIX systems for a customer and found the
easiest way is to make your "menu" shell directly run from .profile This
way, you can "trap" the kill and interrupt signals in the "menu" and when
the menu is exited clean (which it always will be), your next line in
.profile is "exit". This logs out the user. The "menu" must internally
trap signals that would stop the menu script dropping you to a command line
if you use this example. An alternative would be to set the trap command
within .profile ahead of your menu execution. For more info man trap
|lp

EXAMPLE .profile (with a lot of stuff left out)
PS!="My prompt string > "

/home/bin/my_menu
exit

END EXAMPLE

--
Robert Butram
http://www.butram.com

The opinion expressed here may NOT reflect
the reality experienced by others!

Henry Zhaohuiliu wrote in message <785kj2$4$1...@netnews.upenn.edu>...

Michael P. Reilly

unread,
Jan 21, 1999, 3:00:00 AM1/21/99
to
Dan Mercer <dame...@mmm.com> wrote:
: In article <785kj2$4$1...@netnews.upenn.edu>,
: Henry Zhaohuiliu <lscs...@law.upenn.edu> writes:
:> Hello,

:>
:> We tried to terminate a login process from a shell script that is
:> directly logout from the script. The 'exit' command only quit from
:> the script to command line, not directly logout from current
:> login session.
:>
:> I was suggested to use kill -9 -1, it works, but if you use it as a root,
:> then it may kill all the processes.
:>
:> I also tried kill -9 $$, it can kill the current login session if you use
:> it in command line. But if you use it in a script, it just terminate the
:> script and quit to command line.
:>
:> Thank a lot!
:>
:> Henry
:>

Do not use kill -9 for anything until you know what it means, it does
not allow processes to clean up (editors won't save buffers, etc.).
There is a signal just for telling programs that the user is logging
out: SIGHUP (hangup).

: Try:

: logout:
: #!/usr/bin/ksh
: kill -s hup -$$


: if that doesn't work, try:

: #!/usr/bin/ksh
: kill -s hup -$PPID

And if that doesn't work, try:
kill -1 -$$

Not all systems have versions of kill(1) with the "-s" option.

: Dan Mercer

-Arcege


Dan Mercer

unread,
Jan 21, 1999, 3:00:00 AM1/21/99
to
In article <3PHp2.234$QD2....@news.shore.net>,

kill is a shell builtin, not *(/usr)/bin/kill, so I would expect
it to be the same for all ksh's. On HP-UX, /usr/bin/kill does
not support lower case signal names, for instance.

Michael P. Reilly

unread,
Jan 22, 1999, 3:00:00 AM1/22/99
to
Dan Mercer <dame...@mmm.com> wrote:
: In article <3PHp2.234$QD2....@news.shore.net>,

: "Michael P. Reilly" <arc...@shore.net> writes:
:>
:> And if that doesn't work, try:

:> kill -1 -$$
:>
:> Not all systems have versions of kill(1) with the "-s" option.

: kill is a shell builtin, not *(/usr)/bin/kill, so I would expect


: it to be the same for all ksh's. On HP-UX, /usr/bin/kill does
: not support lower case signal names, for instance.

What if the user's system didn't have ksh? Or was using pdksh (which
doesn't support a '-s' option)? It's not something that you can expect
will be there, Dan. Nothing was said about system or shell - so be
general. And the reason I gave "-1" as the signal was to take care of
the systems that don't even handle symbolic names.

-Arcege


Dan Mercer

unread,
Jan 22, 1999, 3:00:00 AM1/22/99
to
In article <xAQp2.342$QD2....@news.shore.net>,

"Michael P. Reilly" <arc...@shore.net> writes:
> Dan Mercer <dame...@mmm.com> wrote:
>: In article <3PHp2.234$QD2....@news.shore.net>,
>: "Michael P. Reilly" <arc...@shore.net> writes:
>:>
>:> And if that doesn't work, try:
>:> kill -1 -$$
>:>
>:> Not all systems have versions of kill(1) with the "-s" option.
>
>: kill is a shell builtin, not *(/usr)/bin/kill, so I would expect
>: it to be the same for all ksh's. On HP-UX, /usr/bin/kill does
>: not support lower case signal names, for instance.
>


It was offered as a ksh solution, not a general solution. I
don't know that pdksh supports PPID either. A more general
solution would probably involve parsing ps output. However, if
the original requestor has real ksh, and the solution fits the
need, it is simple enough to implement and a more general, more
complicated and more difficult is not necessary. There were plenty
of other, more general solutions offered. It's easy enough to try
them out and see which ones work and are most elegant. For instance,
if the user was accessing over a real tty or by rlogin, then:

stty 0

works quite nicely. It has absolutely no effect on an +(x|hp|dt)term
session or a telnet session. Programming for the Least Common
Denominator in a restricted environment is wasteful and unnecessary.


Dan Mercer
dame...@mmm.com

> What if the user's system didn't have ksh? Or was using pdksh
> (which doesn't support a '-s' option)? It's not something that
> you can expect will be there, Dan. Nothing was said about
> system or shell - so be general. And the reason I gave "-1" as
> the signal was to take care of the systems that don't even
> handle symbolic names.
>
> -Arcege

Opinions expressed herein are my own and may not represent those of my employer.


Samuel Carliles

unread,
Jan 24, 1999, 3:00:00 AM1/24/99
to
On Thu, 21 Jan 1999, Michael P. Reilly wrote:

> Dan Mercer <dame...@mmm.com> wrote:
> : In article <785kj2$4$1...@netnews.upenn.edu>,
> : Henry Zhaohuiliu <lscs...@law.upenn.edu> writes:
> :> Hello,
> :>
> :> We tried to terminate a login process from a shell script that is
> :> directly logout from the script. The 'exit' command only quit from
> :> the script to command line, not directly logout from current
> :> login session.
> :>
> :> I was suggested to use kill -9 -1, it works, but if you use it as a root,
> :> then it may kill all the processes.
> :>
> :> I also tried kill -9 $$, it can kill the current login session if you use
> :> it in command line. But if you use it in a script, it just terminate the
> :> script and quit to command line.

in the case that this user need not run anything but this script, why not
make this script that user's shell, such that when the user exits the
script, she exits her shell, and therefore her session?


samuel carliles
ihs...@hops.cs.jhu.edu

Ut-napishtim spoke to him, to Gilgamesh,
'Let me reveal to you a closely guarded matter, Gilgamesh,
And let me tell you the secret of the gods.
There is a [ ] whose [ ] is like [ ],
Whose [ ], like a [ ]'s will [ ] your [ ].
If you yourself can win that [ ], you will find
rejuvenation.

Randal L. Schwartz

unread,
Jan 25, 1999, 3:00:00 AM1/25/99
to
>>>>> "Henry" == Henry Zhaohuiliu <lscs...@law.upenn.edu> writes:

Henry> We tried to terminate a login process from a shell script that
Henry> is directly logout from the script. The 'exit' command only
Henry> quit from the script to command line, not directly logout from
Henry> current login session.

Henry> I was suggested to use kill -9 -1, it works, but if you use it
Henry> as a root, then it may kill all the processes.

Henry> I also tried kill -9 $$, it can kill the current login session
Henry> if you use it in command line. But if you use it in a script,
Henry> it just terminate the script and quit to command line.

If the script is in Perl (and why shouldn't it be? :), then use:

kill 1, getppid;

which nails the process parent with a SIGHUP. That's enough to kill
my login shell here.

--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

0 new messages