Alexander Burger <a...@software-lab.de> writes:
>> is it "normal" that a simple 'kill' won't kill PicoLisp processes, only
>> with option 'KILL it works?
> A "normal" kill with SIGTERM (i.e. -15) should work.
> SIGKILL (i.e. -9) should be used only in extreme emergencies, because it
> may cause the loss of data (resulting in a corrupted database in the
> worst case)!
> Usually a
> $ killall picolisp
> $ killall pil
> should do.
> It should be noted, however, that PicoLisp catches some signals:
> 1. SIGPIPE, SIGTTIN and SIGTTOU are ignored.
> 2. SIGIO is caught and handled in the 'sigio' function handler.
> 3. SIGHUP is caught and handled in the '*Hup' global.
> 4. SIGUSR1 and SIGUSR2 are handled in the '*Sig1' and '*Sig2'
> 5. SIGALRM is used for the 'alarm' and 'abort' functions.
> 6. SIGCHLD is handled internally for the management of child
> 7. SIGINT is caught only in the REPL, and causes a console break. A
> process running without a REPL is terminated.
> 8. SIGTSTP is used in the REPL to suspend the forground PicoLisp
> The "normal" (default) signal SIGTERM causes the termination of the
> running PicoLisp process with 'bye'.
> 1. If that process has still running child processes, it sends
> SIGTERM recursively to all children first, and waits for them to
> terminate. Then it terminates itself.
> 2. During certain phases of program execution, the PicoLisp
> interpreter blocks this and/or other signals. This may be in a
> 'protect'ed code block, or during critical database operations.
> This will only delay the handing of those interrupts (not ignore
> I hope I didn't forget anything :)
Guess not, that reads like an exhaustive treatment ;)
Thanks for the info.
I ran into this problem when experimenting with the web-framework and my
app got into a bad state. When restarting then, PicoLisp tells me
something like 'Port is already used', so I tried to kill the still
running (*) PicoLisp processes with a simple 'kill PID', but to no
[* are they still running? 'ps' shows them with a '?', and I
shutted them down on the command-line, so they shouldn't. But somehow
they still block the port, and the more I shut down, the more are shown
May that be because things went wrong during debugging when some
database operation failed? I have no idea ...