[TUHS] self-reproducing programs

[TUHS] self-reproducing programs

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

Not quite a self reproducing program and I did take down one of the UCSD servers one day.

I was writing a shell script to do some complex and long running task. This was in the early days of the shell supporting functions. The script had a large number of functions and I named one of them to be the same name as the shell script.

I set it in motion and logged out, as I knew it would take several hours to finish the work.

The next day I logged in to find that the machine had the load spike as the shell script recursively started itself when it got to the function call that had the same name as the shell script. The admin kindly sent me a ‘top' output showing the load at several hundred and all the jobs having my name and being my shell script.

Under this he wrote: “Never do this again.”

I haven’t.

	David

[TUHS] self-reproducing programs

[Tony Finch]

Not quite a fork bomb...

I was deploying some new software on a production server. (There wasn't a
good place to test it.) I somehow screwed up the restart logic so it
continuously restarted itself. The process forked, the parent exited, and
the child looped to restart again. There was only ever one instance of the
program running, but its pid changed hundreds of times per second.

Since it had daemonized, I couldn't use process groups to kill it.

Since it was running as root, I couldn't use `kill -TERM -1` to kill just
one user's processes.

Since it was a production server, I reslly didn't want to reboot.

I tried picking a pid somewhat larger than the program's rapidly
increasing pid, and ran a script: while !kill $pid; do :; done

No dice, it just blew straight past.

I wrote a C program to kill that one pid even faster. Still no luck.

In the end I managed to kill it by running about 5 or 10 concurrent copies
of my C program on a set of adjacent pids.

Only fallout was a few FTP server connection failures...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea: Southwest 5 to 7, veering northwest, then backing
southwest later, 4 or 5. Moderate or rough, becoming slight in Irish Sea. Rain
for a time. Good, becoming moderate or poor for a time.

[TUHS] self-reproducing programs

[Random832]

On Thu, Mar 24, 2016, at 10:24, Tony Finch wrote:
> There was only ever one instance of the
> program running, but its pid changed hundreds of times per second.
> 
> Since it had daemonized, I couldn't use process groups to kill it.
> 
> Since it was running as root, I couldn't use `kill -TERM -1` to kill just
> one user's processes.
> 
> Since it was a production server, I reslly didn't want to reboot.
> 
> I tried picking a pid somewhat larger than the program's rapidly
> increasing pid, and ran a script: while !kill $pid; do :; done

Out of a curiosity, if a C program executes kill(-1, SIGSTOP), will it
itself be stopped? Or can SIGSTOP be ignored?

If so, maybe you could have solved it by stopping everything and then
continuing everything but the offending program. Of course, then you
risk that other programs on the system may have side effects from being
stopped and continued (interrupted system calls they may not be able to
handle, etc)