The macosxhints Forums - Horse Menu and killing processes

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- UNIX - General (http://hintsforums.macworld.com/forumdisplay.php?f=16)

- - Horse Menu and killing processes (http://hintsforums.macworld.com/showthread.php?t=12589)

Horse Menu and killing processes

I have Horse Menu (a great menu widget) which (among many other things) allows me to send certain commands to any process, such as STOP, CONT, KILL, INT, HUP, and TERM. The last 4 seem to quit the process in one way or another. What is the difference between KILL, INT, HUP, and TERM? Which one is the safest to use for quitting a process?

pfbbbbbbt and whiney

man kill

and

man 2 kill

programs have to be written to trap signals from kill

The man only says what the abbreviations stand for... what is the basic difference, and which is the safest or closest to manually quitting a process?

well, all of that is steeped in the traditions of the society of the brotherhood of process management and killing things.

either you don't know, or you don't want to tell me :D

(or quite possibly: you don't know AND you don't want to tell me) ;)

I tried Horse Menu a couple of times so thought I would probably have the ReadMe file kicking around somewhere, but I must have deleted it. In an attempt to answer your question I tried to download it only to find it's dissapeared from VersionTracker and the developer's site reports that it's no longer available. On that note, I'd use it with some caution.

As to your question; from what I can remember only some of the commands you list actually quit the programme. For example, I think that HUP merely suspends the running of a programme rather than quitting it. Have a read of the kill man page which deals with some of the ways in which this command can be used.

Quote:

Originally posted by zeb
(or quite possibly: you don't know AND you don't want to tell me) ;)

A logical impossibility, of course Merv knows ;)

By the way, just ignore the crap I posted in my last message about HUP, see:

http://www.onlamp.com/...FreeBSD_Basics.html

Quote:

Originally posted by djn1
and the developer's site reports that it's no longer available.

:eek:
No way!

Quote:

Originally posted by djn1
Have a read of the kill man page which deals with some of the ways in which this command can be used.

I don't want to know how I can use the commands... I want to know which to use. My options seem to be widdled down to KILL, INT, and TERM. Let me be more specific (I'm actually going to be vague and confusing) in my questioning: is KILL like 'force quit', and TERM like 'quit'? Or is TERM just as abrupt as KILL (is KILL abrupt?)?

Quote:

Originally posted by zeb
:eek:
No way!

Yes way - but it's the first I've heard of it.

Quote:

Code:

     Some of the more commonly used signals:

     1       HUP (hang up)

     2       INT (interrupt)

     3       QUIT (quit)

     6       ABRT (abort)

     9       KILL (non-catchable, non-ignorable kill)

     14      ALRM (alarm clock)

     15      TERM (software termination signal)

The list you originally posted aren't separate commands, they're various signals that can be apended to the Kill command. So, as I understand it (which is admittedly not a very sophisticated understanding) Kill -9 is akin to force quit, and from looking at the above list, Kill -15 is more akin to a normal application style quit.

Other than that I guess you'll have to wake for Merv to take his tablets and return to 'normal' ;)

[QUOTE]Originally posted by zeb
By the way, the link in your sig points to:

http://www.zebelis.com/

... rather than:

http://www.zebellis.com/

i.e. there's an 'l' (ell) missing.

Quote:

Originally posted by djn1
...and from looking at the above list, Kill -15 is more akin to a normal application style quit.

okay. Now it makes sense, but I have learned not to make assumptions, so I wanted to ask for verification. The article you pointed me to was good too, thanks.

Quote:

Originally posted by djn1
there's an 'l' (ell) missing.

:eek:
-hanging head in shame- "kan't even spel migh own name..." I will fix it at once!

Quote:

Originally posted by zeb
-hanging head in shame- "kan't even spel migh own name..." I will fix it at once!

To wander many leagues off-topic - I particularly liked your shot of Beech Hill, Rockport, ME. And your site makes mine look like something of an amateur effort - it's depressing :rolleyes:

Quote:

Originally posted by djn1
I particularly liked your shot of Beech Hill, Rockport, ME.

Thanks! ... but do you know what is really depressing?

...

that shot... :( it reminds me of home... (unfortunately, there isn't a smiley with tears flying outward from the face)

Quote:

Originally posted by zeb
that shot... :( it reminds me of home...

Could be worse, you could live where I do - which isn't quite so aesthetically attractive:

http://www.virtualhuddersfield.com/trial.htm

Nice shots of Iceland, Zeb. That's my new favorite place to travel to in Europe.

Here is a Perl script that you can experiment with to understand the signals better. (As usual, you need to save the script into a file and make that file executable via 'chmod +x'.)

The normal way to exit from this program is by pressing q and then Return. If you exit the normal way, the program gets to do its cleanup routine. If you terminate the program by some other means, it doesn't get to do its cleanup.

The main idea I hoped to get across in this example is that what happens when you use 'kill' to terminate a program depends not only on which signal you send, but also on how the program was written - whether it catches signals and what it does with them.

Code:

#!/usr/bin/perl -w



# This script is intended to illustrate the effect of various signals



use strict;



my $delay = 1;

my $count = 0;



# function that gets called upon quit

sub finish()

{

    print "Cleaning up, please wait ...\n";

    for (1 .. 5)

    {

        print ".\n";

        sleep 1;

    }

    print "Finished cleaning up, now exiting\n\n";

    exit;

}



# Signal Handlers:

# These functions get invoked when the script receives the corresponding signal

# Note: signal numbers are in /usr/include/sys/signal.h



sub handle_SIGHUP()  # number 1

{

    print "\nReceived HUP signal\n";

    print "Resetting state\n\n";

    $delay = 1;

    $count = 0;

}



sub handle_SIGINT()  # number 2

{

    print "\nReceived INT signal\n";

    print "Do it again to get the default action\n\n";

    $SIG{INT} = 'DEFAULT';

}



sub handle_SIGQUIT()  # number 3

{

    print "\nReceived QUIT signal\n";

    print "But I'm not going to do anything about it!\n\n";

}



sub handle_SIGKILL()  # number 9, number 9, number 9, ...

{

    # this will never happen - KILL cannot be caught !

    print "\nReceived KILL signal\n";

}



sub handle_SIGTERM()  # number 15

{

    print "\nReceived TERM signal\n";

    print "Do it again to get the default action\n\n";

    $SIG{TERM} = 'DEFAULT';

}



sub handle_SIGSTOP()  # number 17

{

    # this will never happen - STOP cannot be caught !

    print "\nReceived STOP signal\n";

}



sub handle_SIGUSR1()  # number 30

{

    print "\nReceived USR1 signal\n";

    print "Changing delay\n\n";

    $delay = 1 if ++$delay > 3;;

}



sub setup_signals()

{

    $SIG{HUP}  = \&handle_SIGHUP;   #  1

    $SIG{INT}  = \&handle_SIGINT;   #  2

    $SIG{QUIT} = \&handle_SIGQUIT;  #  3

    $SIG{KILL} = \&handle_SIGKILL;  #  9

    $SIG{TERM} = \&handle_SIGTERM;  # 15

    $SIG{STOP} = \&handle_SIGSTOP;  # 17

    $SIG{USR1} = \&handle_SIGUSR1;  # 30

}



sub setup_input()

{

    use Fcntl;



    # We want non-blocking input (so the script doesn't wait for input)

    # Note that it might be necessary to call this again if STDIN got reset

    # by the shell (e.g. after a STOP signal)



    my $flags = 0;

    fcntl(STDIN, F_GETFL, \$flags)

        or die "Couldn't get flags for STDIN : $!\n";



    $flags |= O_NONBLOCK;

    fcntl(STDIN, F_SETFL, $flags)

        or die "Couldn't set flags for STDIN: $!\n";

}



sub check_for_quit()

{

    my $input;



    if (read(STDIN, $input, 1))

    {

        return 1 if lc($input) eq 'q';

    }

    return 0;

}





# -- MAIN --



setup_signals();

setup_input();



print "\nWelcome to the 'testsignals' script\n";

print "The PID of this script is $$\n";

print "Try sending it various signals via the 'kill' command\n";

print "from another window. (E.g. kill -1 $$)\n";

print "Signals: HUP = 1, INT = 2, QUIT = 3, KILL = 9\n"; 

print "         TERM = 15, STOP = 17, USR1 = 30\n"; 

print "Also try keyboard actions like control-C, control-Z, control-\\\n";

print "\n";



while (1)

{

    ++$count;

    print "Working $count (Type q followed by Return to quit)\n";

    if (check_for_quit())

    {

        print "Okay, I'm quitting now\n";

        finish();

    }

    sleep $delay;

}

print "How did we get here? (Shouldn't ever happen)\n";

exit;

Quote:

Originally posted by yellow
That's my new favorite place to travel to in Europe.

Have you been? I was blown away! Absolutuely the most beautiful place I have ever seen. I'm sure I'll be going back... once, uh, once I make some more money... designing web sites isn't quite paying off (but it is fun).

hayne - okay, I've saved the file into /usr/local/bin/ and titled it 'killing.sh' (I don't really know why the '.sh') and cd-ed into that directory, typed 'chmod +x killing.sh', then tried typing 'killing.sh' and just 'killing' to call the script, but it keeps saying 'command not found'... as you can see, I know very little about creating custom scripts and executing them... what do I do?

./killing.sh

the ./ tells it to look in the local directory... otherwise it tries to find the binary following your PATHs.

Yep, been there once in March, next trip will be in July of next year.

Quote:

Originally posted by yellow
./killing.sh

the ./ tells it to look in the local directory... otherwise it tries to find the binary following your PATHs.

Yep, been there once in March, next trip will be in July of next year.

March seems like a good time to go. I was there in December (on the solstice actually. Not too much sun - about 5 hours worth of good photographing light...) But that was one of the reasons for going at that time; I thought it would be quite dark and have really long nights (great for photographing the northern lights) but it turns out that since the sun doesn't actually stray tat far from the horizon during the two solstices, it doesn't actually get that dark. So I didn't see any Aurora. Where did you go when you were there? I took the southern route - down as far as Jökulsárlón (the lagoon in those photos). I highly recommend that place!

As for the script: thanks, that got it working. Interesting example, thanks hayne. So it seems like TERM (#15) is the most appropriate out of the original four options... as far as the cleanest way to end a process... if that doesn't actually quit the process, then use KILL (#9)... Is this somewhat accurate?

It was very beautiful, rugged country.. I didn't make it that far down south(east). Furthest I went was to go up on the small glacier to the west of Jökulsárlón. I got some great pictures as well and I'm not a very good photographer.

I would agree with your assesment of kill. I usually just use 'kill -9' (old habit).