Hi

I am writing an application using lazdaemon. How does one stop the daemon gracefully, ie not killing it.

The wiki says the daemon runs until it receives the TERM signal. THe only way I know to send the TERM signal is using 'kill'. This kills the app rather letting it exit gracefully.

Thanks
Wimpie

In our previous episode, Wimpie Nortje said:

Known issue, see

http://bugs.freepascal.org/view.php?id=14741

there are some more signals that are handled.

Are there plans to fix/change this, or must I implement some kind of pid check myself?

I also see a mention of a '-b' parameter in the report but it doesn't daemonize my application. Is it new? I am using fpc 2.2.4

You can send any defined signal using kill. Try:

# kill -TERM <yourdeamon>

for sending the TERM signal. At least FreeBSDs kill works that way. If yours doesn't try:

$ man kill

HTH,

In our previous episode, Wimpie Nortje said:

No plans yet. The problem is also a bit that whatever you do is an island. I think this is more something for freedesktop to standarize first.

I also see a mention of a '-b' parameter in the report but it doesn't daemonize my application. Is it new? I am using fpc 2.2.4

It's in combination with start only. I just happened to look in those sources today before your msg because of the above report. I don't know the history.

I know there is a standard/recomended way to write a daemon. If you use KDevelop it will create such a template. I don't know if that includes stopping the daemon but I will have a look there.

That is what I did. This doesn't run my daemon's exit routines. I don't know if Linux just kills the daemon or if the daemon receives the signal and exits properly without calling the exit routines.

It should stop the daemons properly. This is the code that gets executed:

Procedure DoShutDown(Sig : Longint; Info : PSigInfo; Context : PSigContext);
cdecl;
begin
   Application.StopDaemons(True);
   Application.Terminate;
end;

If it doesn't, something is wrong :(

Michael.

In our previous episode, Wimpie Nortje said:

A daemon and starting stopping it are two different things.

I don't know if that includes stopping the daemon but I will have a look there.

To my best knowledge, the scripts in init.d/ etc handle the starting and stopping and storing PIDs, not the applications themselves.

I think something is wrong. :(

For my TDaemon descendant I assigned the following events: OnDestroy
OnExecute
OnPause
OnShutdown
OnStart
OnStop

When I type "./daemon -r &"
The following handlers are executed:
1. OnStart
2. OnExecute

When I type "kill -TERM daemon_pid"
The following handler is executed
1. OnDestroy

I am also a bit confused by the wiki. According to the wiki Start and stop are triggered under linux but shutdown is not. The 'Taming the daemon' article does not specify which of these 3 are called under linux.

As I mentioned earlier, I use FPC 2.2.4. Could that be the problem?

Are both of these routines and all code they call safe for asynchronous execution? (i.e., can they be safely called when the program was in the middle of a getmem, I/O operation, ...) Usually the most you should ever do inside a signal handler is set some global variable, because you have no idea what code is currently actually executing.

Jonas

I don't know how I did it exactly, but I ahve this working properly in a production system. (Even created my own SysV init script for it. It should be generally usable for all fpc-daemon applications)

But I did use fpc 2.3.1, so try the new 2.4.0rc1. And I think that it won't work always now I've read Jonas' mail about it. Maybe I'll look at that later.

Joost.

That's good news: I had it on my todo list to let the 'Install' mode generate this script in the appropriate directory. If I can use your script as a start, then I can implement that.

Michael.

Thanks, I will try the new compiler.

See below. Description and daemonname/filenames should be adapted, offcourse.

#!/bin/bash
#
# startupmaildaemon startup script for the IA-MailDaemon #
# chkconfig: - 2345 20 80
# description: MailDaemon wordt gebruikt om mailtjes die geagendeerd zijn om \ # te versturen in de IA ook daadwerkelijk te versturen # processname: maildaemon
# pidfile: /var/run/maildaemon.pid

. /etc/rc.d/init.d/functions

prog=MailDaemon
maildaemon=${MAILDAEMON-/opt/maildaemon/maildaemon} pidfile=${PIDFILE-/var/run/maildaemon.pid}
lockfile=${LOCKFILE-/var/lock/subsys/maildaemon}
runasuser=${RUNUSER-apache}
RETVAL=0

start() {
echo -n $"Starting $prog: "
sudo -b -u $runasuser $maildaemon -b -r
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch ${lockfile}
return $RETVAL
}

stop() {
echo -n $"Stopping $prog: "
killproc -d 10 $maildaemon
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f ${lockfile} ${pidfile}
}

case "$1" in
start)
start

        ;;
  stop)
        stop
        ;;
  restart)
        stop
        start
        ;;
  *)
         echo "Usage: $0 {start|stop|restart}"
         exit 1

esac
exit 0

2009/11/9 Michael Van Canneyt :

I've got /etc/init.d/skeleton (in debian), which looks like a very good place to start.

Henry

Michael Van Canneyt :

As wrong as in "Don't call most system functions from within a signal handler.", maybe?

Vinzent.

Hmm... In that case, many exceptions would not work either ?

Michael.

The sigaction handlers for catching exceptions have been fixed quite a while ago already to only collect the necessary information from the signal context, and to then return from the signal handler to the start of the RTL function that handles run time errors, passing this info as arguments (we can pass at least 3 items on every platform by modifying the parameter register contents in the signal context; we also change the instruction pointer in the context so that it returns to the RTL's runerror handler rather than to wherever the signal was triggered).

Jonas

Jonas Maebe :

Additionally, signals causing run-time exceptions are triggered by the code itself, meaning things like SIGSEGV[*] are not actually "interrupting", rather they synchronously "transfer control" in a relatively well-defined way.

Maybe the analogy to good ol' DOS programming helps: Then signals are just interrupts, "synchronous" signals are "int xx" instructions, while "asynchronous" are real "hardware interrupts". Unfortunately you'll never know which will be which. ;)

Vinzent.

[*] Of course, the SIGSEGV still could have been sent from another process making it interrupting and asynchronous like any other signal.

Hm.
Quite complex code, and not processor independent. Is there not a more generic way of handling this ?

Michael.

Michael Van Canneyt wrote

Hm. Quite complex code, and not processor independent.

It never was processor-independent, because the siginfo codes already varied between architectures.

Is there not a more generic way of handling this ?

I doubt it.

Jonas

I remember days when it was processor-independent, because the initial signal handlers only had the signal numbers as an argument.

But that's many many winters ago :-)

> Is there not a more generic way of handling this ? I doubt it.

Very bad :(

Michael.