A program you CAN'T kill with kill -9

A program you CAN'T kill with kill -9

Post by Brian La » Thu, 23 Mar 1995 05:03:53



: Hello to all Linux programmers, or to those who know at least a bit more
: than I do about UNIX programming. I enclose a binary of a program at the
: end of this message, without the source, since the source wasn't given to
: me, because the guy who wrote it just doesn't want to give it to me(he
: thinks it's too cool of a program).

  What kind of idiots do you think we are? Running an unknown binary on my
machine?

  I DON'T THINK SO!

  I would advise anyone seeing this post to NOT run it unless you really
know what you are doing!

      Brian
--
------------------------------------------------------------------------------
 "Everyone is a prisoner holding their own key." |      (360)569-2911
  http://www.eskimo.com/~blane/                  |   Electronics/uP files
------------------------------------------------------------------------------

 
 
 

A program you CAN'T kill with kill -9

Post by John R. Dennis » Thu, 23 Mar 1995 13:33:27


In article <D5t3qH....@eskimo.com>, Brian Lane <bl...@eskimo.com> wrote:
>Mr. Brownstone (ind01...@pegasus.cc.ucf.edu) wrote:
>: Hello to all Linux programmers, or to those who know at least a bit more
>: than I do about UNIX programming. I enclose a binary of a program at the
>: end of this message, without the source, since the source wasn't given to
>: me, because the guy who wrote it just doesn't want to give it to me(he
>: thinks it's too cool of a program).

>  What kind of idiots do you think we are? Running an unknown binary on my
>machine?

>  I DON'T THINK SO!

>  I would advise anyone seeing this post to NOT run it unless you really
>know what you are doing!

        Well, I can't say that I *really* knew what I was doing, but I
        ran the supplied program in a somewhat controlled environment
        for the hell of it.  Perhaps someone with a more extensive knowledge
        of Linux low-level stuff could correct or fill in any missing
        information from the junk below.

        I ran it under strace -T -f, here is the initial output file,
        and 1 additional as spawned via strace when the original process
        forked (I *think*, I may be wrong on this, as this is one of the
        few times I have had a real reason to use strace, and I may be
        confused as to how it handles output files.

        Anyways, heres the first output file:

uselib("/lib/ld.so") = 0 <0.072378>
stat("/etc/ld.so.cache", {dev 3 3 ino 4116 mode 0100644 nlink 1 uid 0 gid 0 size 748 ...}) = 0 <0.007537>
open("/etc/ld.so.cache", RDONLY) = 4 <0.003095>
mmap(0, 748, READ, SHARED, 4, 0) = 0x50000000 <0.006786>
close(4) = 0 <0.006148>
uselib("/lib/libc.so.4.5.26") = 0 <0.005080>
munmap(0x50000000, , 748, ) = 0 <0.002779>
munmap(0x62f00000, , 16384, ) = 0 <0.013675>
brk(0) = 0x2000 <0.001728>
pipe([4, 5]) = 0 <0.012273>
pipe([6, 7]) = 0 <0.002132>
fork() = 178 <0.014079>
 [pid 177]: close(7) = 0 <0.004632>
 [pid 177]: close(4) = 0 <0.001840>
 [pid 177]: write(5, "o", 1) = 1 <0.002376>
 [pid 177]: read(6, "o", 1) = 1 <0.016419>
 [pid 177]: sigaction(SIGHUP, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.003439>
 [pid 177]: sigaction(SIGHUP, NULL, {0x2a4, [HUP INT QUIT TSTP], RESTART}) = 0 <0.003028>
 [pid 177]: sigaction(SIGINT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.003845>
 [pid 177]: sigaction(SIGINT, NULL, {0x2a4, [INT QUIT TSTP], RESTART}) = 0 <0.002163>
 [pid 177]: sigaction(SIGQUIT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.003099>
 [pid 177]: sigaction(SIGQUIT, NULL, {0x2a4, [INT QUIT TSTP], RESTART}) = 0 <0.002055>
 [pid 177]: sigaction(SIGILL, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002665>
 [pid 177]: sigaction(SIGILL, NULL, {0x2a4, [INT QUIT ILL TSTP], RESTART}) = 0 <0.002053>
 [pid 177]: sigaction(SIGTRAP, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002543>
 [pid 177]: sigaction(SIGTRAP, NULL, {0x2a4, [INT QUIT TRAP TSTP], RESTART}) = 0 <0.002224>
 [pid 177]: sigaction(SIGABRT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002561>
 [pid 177]: sigaction(SIGABRT, NULL, {0x2a4, [INT QUIT ABRT TSTP], RESTART}) = 0 <0.002053>
 [pid 177]: sigaction(SIGUNUSED, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002539>
 [pid 177]: sigaction(SIGUNUSED, NULL, {0x2a4, [INT QUIT UNUSED TSTP], RESTART}) = 0 <0.002090>
 [pid 177]: sigaction(SIGFPE, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002543>
 [pid 177]: sigaction(SIGFPE, NULL, {0x2a4, [INT QUIT FPE TSTP], RESTART}) = 0 <0.002592>
 [pid 177]: sigaction(SIGKILL, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = -1 (Invalid argument) <0.002555>
 [pid 177]: sigaction(SIGKILL, NULL, {0x2a4, [INT ILL ABRT UNUSED FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH LOST 30 31 32], 0}) = -1 (Invalid argument) <0.003260>
 [pid 177]: sigaction(SIGUSR1, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002675>
 [pid 177]: sigaction(SIGUSR1, NULL, {0x2a4, [INT QUIT USR1 TSTP], RESTART}) = 0 <0.002055>
 [pid 177]: sigaction(SIGSEGV, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002542>
 [pid 177]: sigaction(SIGSEGV, NULL, {0x2a4, [INT QUIT SEGV TSTP], RESTART}) = 0 <0.002164>
 [pid 177]: sigaction(SIGUSR2, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.002540>
 [pid 177]: sigaction(SIGUSR2, NULL, {0x2a4, [INT QUIT USR2 TSTP], RESTART}) = 0 <0.002056>
 [pid 177]: sigaction(SIGPIPE, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.003822>
 [pid 177]: sigaction(SIGPIPE, NULL, {0x2a4, [INT QUIT PIPE TSTP], RESTART}) = 0 <0.006541>
 [pid 177]: sigaction(SIGALRM, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.007104>
 [pid 177]: sigaction(SIGALRM, NULL, {0x2a4, [INT QUIT ALRM TSTP], RESTART}) = 0 <0.006812>
 [pid 177]: sigaction(SIGTERM, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006577>
 [pid 177]: sigaction(SIGTERM, NULL, {0x2a4, [INT QUIT TERM TSTP], RESTART}) = 0 <0.006281>
 [pid 177]: sigaction(SIGSTKFLT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006456>
 [pid 177]: sigaction(SIGSTKFLT, NULL, {0x2a4, [INT QUIT STKFLT TSTP], RESTART}) = 0 <0.005970>
 [pid 177]: sigaction(SIGCHLD, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006564>
 [pid 177]: sigaction(SIGCHLD, NULL, {0x2a4, [INT QUIT CHLD TSTP], RESTART}) = 0 <0.006005>
 [pid 177]: sigaction(SIGCONT, NULL, SIG_DFL) = 0 <0.005737>
 [pid 177]: sigaction(SIGCONT, SIG_DFL, NULL) = 0 <0.007880>
 [pid 177]: sigaction(SIGSTOP, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = -1 (Invalid argument) <0.006276>
 [pid 177]: sigaction(SIGSTOP, NULL, SIG_DFL) = -1 (Invalid argument) <0.006065>
 [pid 177]: sigaction(SIGTSTP, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006516>
 [pid 177]: sigaction(SIGTSTP, NULL, {0x2a4, [INT QUIT TSTP], RESTART}) = 0 <0.006085>
 [pid 177]: sigaction(SIGTTIN, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_IGN) = 0 <0.006606>
 [pid 177]: sigaction(SIGTTIN, NULL, {0x2a4, [INT QUIT TSTP TTIN], RESTART}) = 0 <0.005946>
 [pid 177]: sigaction(SIGTTOU, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_IGN) = 0 <0.006643>
 [pid 177]: sigaction(SIGTTOU, NULL, {0x2a4, [INT QUIT TSTP TTOU], RESTART}) = 0 <0.007125>
 [pid 177]: sigaction(SIGIO, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.007205>
 [pid 177]: sigaction(SIGIO, NULL, {0x2a4, [INT QUIT TSTP IO], RESTART}) = 0 <0.006042>
 [pid 177]: sigaction(SIGXCPU, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006478>
 [pid 177]: sigaction(SIGXCPU, NULL, {0x2a4, [INT QUIT TSTP XCPU], RESTART}) = 0 <0.005961>
 [pid 177]: sigaction(SIGXFSZ, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006598>
 [pid 177]: sigaction(SIGXFSZ, NULL, {0x2a4, [INT QUIT TSTP XFSZ], RESTART}) = 0 <0.006027>
 [pid 177]: sigaction(SIGVTALRM, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006523>
 [pid 177]: sigaction(SIGVTALRM, NULL, {0x2a4, [INT QUIT TSTP VTALRM], RESTART}) = 0 <0.005937>
 [pid 177]: sigaction(SIGPROF, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006559>
 [pid 177]: sigaction(SIGPROF, NULL, {0x2a4, [INT QUIT TSTP PROF], RESTART}) = 0 <0.006031>
 [pid 177]: sigaction(SIGWINCH, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006464>
 [pid 177]: sigaction(SIGWINCH, NULL, {0x2a4, [INT QUIT TSTP WINCH], RESTART}) = 0 <0.006488>
 [pid 177]: sigaction(SIGLOST, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006855>
 [pid 177]: sigaction(SIGLOST, NULL, {0x2a4, [INT QUIT TSTP LOST], RESTART}) = 0 <0.006012>
 [pid 177]: sigaction(SIG30, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006511>
 [pid 177]: sigaction(SIG30, NULL, {0x2a4, [INT QUIT TSTP 30], RESTART}) = 0 <0.006096>
 [pid 177]: sigaction(SIG31, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.007441>
 [pid 177]: sigaction(SIG31, NULL, {0x2a4, [INT QUIT TSTP 31], RESTART}) = 0 <0.005543>
 [pid 177]: sigaction(SIGINT, {0x1b4, [INT QUIT TSTP], RESTART}, NULL) = 0 <0.006572>
 [pid 177]: sigaction(SIGQUIT, {0x1b4, [INT QUIT TSTP], RESTART}, NULL) = 0 <0.007697>
 [pid 177]: sigaction(SIGTSTP, {0x1b4, [INT QUIT TSTP], RESTART}, NULL) = 0 <0.005692>
 [pid 177]: sigaction(SIGCHLD, SIG_IGN, NULL) = 0 <0.007722>
 [pid 177]: sigaction(SIGPIPE, {0x184, [INT QUIT TSTP], RESTART}, NULL) = 0 <0.005600>
 [pid 177]: read(6, 0xbffffcd7, 1) (RESTARTSYS) <20.274201>

        and heres the next:

 [pid 178]: setsid() = 178 <0.015515>
 [pid 178]: close(5) = 0 <0.002101>
 [pid 178]: close(6) = 0 <0.001888>
 [pid 178]: write(7, "o", 1) = 1 <0.004035>
 [pid 178]: read(4, "o", 1) = 1 <0.089646>
 [pid 178]: sigaction(SIGHUP, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006724>
 [pid 178]: sigaction(SIGHUP, NULL, {0x2a4, [HUP INT QUIT TSTP], RESTART}) = 0 <0.006215>
 [pid 178]: sigaction(SIGINT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006771>
 [pid 178]: sigaction(SIGINT, NULL, {0x2a4, [INT QUIT TSTP], RESTART}) = 0 <0.005694>
 [pid 178]: sigaction(SIGQUIT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006338>
 [pid 178]: sigaction(SIGQUIT, NULL, {0x2a4, [INT QUIT TSTP], RESTART}) = 0 <0.005663>
 [pid 178]: sigaction(SIGILL, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.005908>
 [pid 178]: sigaction(SIGILL, NULL, {0x2a4, [INT QUIT ILL TSTP], RESTART}) = 0 <0.005687>
 [pid 178]: sigaction(SIGTRAP, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006031>
 [pid 178]: sigaction(SIGTRAP, NULL, {0x2a4, [INT QUIT TRAP TSTP], RESTART}) = 0 <0.005794>
 [pid 178]: sigaction(SIGABRT, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.006418>
 [pid 178]: sigaction(SIGABRT, NULL, {0x2a4, [INT QUIT ABRT TSTP], RESTART}) = 0 <0.006270>
 [pid 178]: sigaction(SIGUNUSED, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.005710>
 [pid 178]: sigaction(SIGUNUSED, NULL, {0x2a4, [INT QUIT UNUSED TSTP], RESTART}) = 0 <0.005712>
 [pid 178]: sigaction(SIGFPE, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = 0 <0.005912>
 [pid 178]: sigaction(SIGFPE, NULL, {0x2a4, [INT QUIT FPE TSTP], RESTART}) = 0 <0.005734>
 [pid 178]: sigaction(SIGKILL, {0x2a4, [INT QUIT TSTP], RESTART}, SIG_DFL) = -1 (Invalid argument) <0.006008>
 [pid 178]: sigaction(SIGKILL, NULL,
...

read more »

 
 
 

A program you CAN'T kill with kill -9

Post by Marc J. Fraio » Fri, 24 Mar 1995 01:13:50


|>From the output of the strace, it seems likely that the program remaps
|>the default action taken when it recieves signals like SIGSEGV, SIGINT,
|>SIGTERM, etc, which is a simple thing to do in C (and is quite
|>commonplace), and then it forks off processes which drown the machine.  
|>
Well, there was a way of doing this that works under SunOS 4.1.3,
although I've never tried it under Linux.  Basically what you do
is use ptrace(2).  The program starts, then calls fork(2).  The
child makes itself traceable, and the parent traces it.  Now, when
a signal is delivered to the child, the parent gets to see it first
and decide what to do about it.  Under Ultrix, I remember, a SIGSTOP
or SIGKILL would still kill it, but under SunOS, the tracing process
would see the delivery of this signal and could choose to ignore it,
and just tell the traced process to resume.  Of course, the clever
person would spot the parent process (probably running under an
assumed name with cute use of exec(2)) and kill that...

--
Marc Fraioli          | "They couldn't hit an elephant at this dist- "
Data General Corp     |    - Last words of Union General John Sedgwick,

 
 
 

A program you CAN'T kill with kill -9

Post by Matt.. » Thu, 23 Mar 1995 19:01:26



>    The virtual with the "shutdown -rt 0" set to fire off never
>    seemed to have its RETURN key accepted to set the shutdown in
>    motion, which is not surprising, the system was bogged down with
>    fork () attempts.

From the output of the strace, it seems likely that the program remaps
the default action taken when it recieves signals like SIGSEGV, SIGINT,
SIGTERM, etc, which is a simple thing to do in C (and is quite
commonplace), and then it forks off processes which drown the machine.

______________________________________________________________________________
Matt...
Computer Science Faculty              Ars longa,
University of New Brunswick          Vita brevis.
Voice: (506) 457-2465              The lyf so short,

______________________________________________________________________________

 
 
 

A program you CAN'T kill with kill -9

Post by Jeffrey Herri » Thu, 23 Mar 1995 22:54:34



Quote:

>        This brings to mind a question I have been meaning to ask in one
>        of the c.o.l.* groups:  is there a way of un-assembling a binary
>        under Linux back into some type of recognizable format, like either
>        assembly or C?

Verrry tough if not impossible to do for 'C because of the effect that
various optimizing compilers have (ie loop unrolling, wanton
variable eliminiation) on the original source input. The
possibility of generating an equivalent assembly source might
be a little better but I gave up on assembly a long time ago
and can't comment ;)

Jeff H

 
 
 

A program you CAN'T kill with kill -9

Post by Perry F Nguy » Fri, 24 Mar 1995 13:45:37


I tried - it crashed my comp a few times
What it seems to do is - when it's killed ; fork itself a zillion times
Either that, or fork a copy of itself that eats all mem up

I crashed w/ a kernel message of out of mem for process killme
Several times in fact.
--
--
               __________                             ___________
               \______   \ __________________ ___.__. \_   _____/
                |     ___// __ \_  __ \_  __ <   |  |  |    __)  
                |    |   \  ___/|  | \/|  | \/\___  |  |     \  
                |____|    \___  >__|   |__|   / ____|  \___  /  
                              \/              \/           \/    

                           Finger for PGP public key.

 
 
 

A program you CAN'T kill with kill -9

Post by Andy Davido » Fri, 24 Mar 1995 14:08:06



: I tried - it crashed my comp a few times
: What it seems to do is - when it's killed ; fork itself a zillion times
: Either that, or fork a copy of itself that eats all mem up
: I crashed w/ a kernel message of out of mem for process killme
: Several times in fact.

grats! why dontcha stick it in yer rc.local?
someone already posted an indepth analysis of this program.

 
 
 

A program you CAN'T kill with kill -9

Post by Bill Bry » Fri, 24 Mar 1995 01:38:03


: Hello to all Linux programmers, or to those who know at least a bit more
: than I do about UNIX programming. I enclose a binary of a program at the
: end of this message, without the source, since the source wasn't given to
: me, because the guy who wrote it just doesn't want to give it to me(he
: thinks it's too cool of a program).
:
: The program, I was told, can NOT supposedly be killed with 'kill -9'
: which I confirmed myself by running it as a regular user under my 1.2.1
: kernel. I do NOT know what EXACTLY it does, but RIGHT after I ran it, the
: machine AVERAGE load went 254, within a matter of 1 second or maybe even
: less. Someone PLEASE run it on their machine, and give me a clue as to
: what EXACTLY this little mean son of a * is doing... It has been
: teasing me forever to find out, I don't have the time to read man
: pages... or books... It's not some trap, or a "Trojan" or whatever. I
: would not dare post anything like that, nor could I take the heat for
: posting such a thing. It's just a 9k program, that when run, all I know
: is, it gets the load to 255-6 on my dx2/66 w/16 megs RAM, and when I somehow
: got a 'ps ax' from another vc, it showed something to the effect of:
:
: ##    ....    R       (getty)
:                 R       (getty)
:               R       (getty)
:               R       (getty)
:               R       (getty)
:                       ...
:
: And that was it... The program however, dies normally if you kill it with
: -2( ^C) , -1 or -15 I think. Log in as a regular NON-root user, execute
: it, log in one more time as the same non-root user, and try 'kill -9
: PIDofKillmeProcess' and type up 'uptime' in another WINDOW as FAST as you
: can, because this * brings the load up to 256 in less than a
: second.... If someone tells me what's going on when this little shit is
: run, I will be eternally greatful to him/her. Thank you. (uuencoded
: binary follows).
:
: btw, I also would like to know what does it mean when a process is
: enclosed like (getty) or (startx) in parenthesis. I always thought it
: meant that a process is SWAPPED out to disk, but in THIS case, there was
: an R next to the getty's(not a SW which would mean it's swapped out) and
: they were still marked as R    (getty).
:
: I had also tried a smart 'fork()' bomb on my computer, which brings the
: load up to 256 eventually, but in a much LONGER period of time than this
: 'killme' program does, that I enclose below. I hope someone takes the time
: to analyze it. It's been a * for me, and I don't know this much
: UNIX...
:
: Thank you for anyone's efforts.
:
:       B-stone
:
: begin 700 killme

Just a comment. Does anyone remember when there was a bug with the
operating system and there was a program that would demonstrate the
bug.  The bug was ( I think ) that the machine would crash if it ran
out of virtual memory instead of refussing to provide anymore resources.
I think the test program spawned off processes as fast as it could to
that it could get to the point of breaking rapidly.  Is this killme the
test program that was written to perform the test - by spawing getties.

The opinion above is mine, not the opinion of my employer.
.

 
 
 

A program you CAN'T kill with kill -9

Post by David LUY » Fri, 24 Mar 1995 04:50:52


: From the output of the strace, it seems likely that the program remaps
: the default action taken when it recieves signals like SIGSEGV, SIGINT,
: SIGTERM, etc, which is a simple thing to do in C (and is quite
: commonplace), and then it forks off processes which drown the machine.  
Signals 9 and 18 (correct me if these are the wrong two) can NOT be trapped...
simple program to check (pseudocode from c & orwell)

  printf_int(int) == signal(int,printf_int); printf("%d raise ok.\n", int)

  main(argc,**argv,**env)
  for(x in [1..31]) signal(x,printf_int) | x <- [1..31]
  for(x in [1..31] - [9,18]) raise(x)
  printf("All signals caught.\n");

Should work ; remove the 9 or 18 from the non-selector list and it won't
(9 will do a sure-kill, 18 will do a sure-suspend).

Signal 9 can be avoided, but only by going into the equiv of OSF/1 stat U
(U == uninteruptible sleep) - this is not as easy as doing a trap...
(probably Linux stat U but I can't remember seing it recently)...

BTW: anyone know how to change signal-handlers and not have to re-change
each time the signal is received?

 
 
 

A program you CAN'T kill with kill -9

Post by David LUY » Fri, 24 Mar 1995 05:40:42


: Signals 9 and 18 (correct me if these are the wrong two) can NOT be trapped...
: simple program to check (pseudocode from c & orwell)
:
:   printf_int(int) == signal(int,printf_int); printf("%d raise ok.\n", int)
:
:   main(argc,**argv,**env)
:   for(x in [1..31]) signal(x,printf_int) | x <- [1..31]
:   for(x in [1..31] - [9,18]) raise(x)
:   printf("All signals caught.\n");
^^^^^^ it was late... I removed most of the orwell stuff and forgot to
remove the reference of the last bit... it sould have been more like...
(ie. it was 2:00am now it is 4:30am I am awake...)

: Signals 9 and 18 (correct me if these are the wrong two) can NOT be trapped...
: simple program to check:
:
:   void printf_int(int x) {signal(x,printf_int); printf("raise(%d) ok.\n", x);}
:
:   main(int argc,char **argv,char **env) {
:   for(x in [1..31]) signal(x,printf_int);
:   for(x in ([1..31] -- [9,18])) raise(x);
:   printf("All signals caught.\n");
:   }
:
:
: OK, a bit of pseudocode in there, but you get the idea...

 
 
 

A program you CAN'T kill with kill -9

Post by Gerald Fiedl » Fri, 24 Mar 1995 00:25:33



> Hello to all Linux programmers, or to those who know at least a bit more
> than I do about UNIX programming. I enclose a binary of a program at the
> end of this message, without the source, since the source wasn't given to
> me, because the guy who wrote it just doesn't want to give it to me(he
> thinks it's too cool of a program).

I don't run a binary whose source i haven't falsified myself !

Quote:> The program, I was told, can NOT supposedly be killed with 'kill -9'
> which I confirmed myself by running it as a regular user under my 1.2.1
> kernel. I do NOT know what EXACTLY it does, but RIGHT after I ran it, the
> machine AVERAGE load went 254, within a matter of 1 second or maybe even
> less. Someone PLEASE run it on their machine, and give me a clue as to
> what EXACTLY this little mean son of a * is doing... It has been

It is not possible to speed up the load average from 0 to 256
whitin 1 second ( because the load average is an average by definition )
whitout having 15360 running processes at the same time or manipulating
the /proc filesystem or/and the kernel.

For what (?) ever you need this f* program: move it to /dev/null !

--
--
Name : Gerald Fiedler                 | Address: Reichenhainerstr. 51/303

URL  : http://www.veryComputer.com/~gfi |          Germany

 
 
 

A program you CAN'T kill with kill -9

Post by Berni » Sat, 25 Mar 1995 06:48:57




>: Hello to all Linux programmers, or to those who know at least a bit more
>: than I do about UNIX programming. I enclose a binary of a program at the
>: end of this message, without the source, since the source wasn't given to
>: me, because the guy who wrote it just doesn't want to give it to me(he
>: thinks it's too cool of a program).
>  What kind of idiots do you think we are? Running an unknown binary on my
>machine?

Why not? That's what test logins are for.... if you plan to gon on the Net
or to open your system to the public, anybody might do stuff like this.

I ran the thing under its own login, and sure it is a fork bomb, just taking
care of most signals. The solution is the usual one --- do a
"killall -19 killme" followed by a "killall -9 killme". The first one will
stop all processes, the second one will kill them one after the other. No
harm done....

Bernie

 
 
 

A program you CAN'T kill with kill -9

Post by Andy Hea » Sat, 25 Mar 1995 23:34:25



Quote:

>Hello to all Linux programmers, or to those who know at least a bit more
>than I do about UNIX programming. I enclose a binary of a program at the
>end of this message, without the source, since the source wasn't given to
>me, because the guy who wrote it just doesn't want to give it to me(he
>thinks it's too cool of a program).

I'm amazed you have such time to waste
 
 
 

1. A method to kill process that cannot be killed even with `kill -9'.

Try this method:
kill -9 non-killed-pid
/usr/proc/bin/prun non-killed-pid
/usr/proc/bin/pmap non-killed-pid
This method works perfectly with Solaris 6. Sometimes you can do it
without the "kill -9 non-killed-pid"

P.S. I don't know about other versions and about some hardware programs,
like tar.

--
------------------------------------------------------
Eugene S. Ilchenko, System Network Administrator
http://secinf.net/

2. would you recommend me where I can find simple ftp client source?

3. how to kill a process when kill -9 won't

4. Window Anomally With Number 9

5. kill -9 doesn't kill (continued)

6. Help wanted using Seagate drive and BIOS extension

7. Kill -9 won't kill a process

8. Two applications read from one port

9. kill -9 doesn't kill a process!

10. kill -9 doesn't kill a process

11. kill -9 doesn't kill a process ?

12. why doesn't "kill -9 -1" kill KDE control-panel

13. Can a process kill its child if it's killed -9