On 01/14/2014 12:59 PM, Mark Morgan Lloyd wrote:
They'll get a TERM first, and five seconds later a KILL. You don't
want to restart after that first signal, because if you wait until the
second one you risk leaving files etc. associated with the program in
an indeterminate state. I've had Qem
On 01/14/2014 12:59 PM, Mark Morgan Lloyd wrote:
They'll get a TERM first, and five seconds later a KILL. You don't
want to restart after that first signal, because if you wait until the
second one you risk leaving files etc. associated with the program in
an indeterminate state. I've had Qem
Michael Schnell wrote:
On 01/14/2014 12:07 PM, Mark Morgan Lloyd wrote:
You need to make sure that it doesn't try to restart if it's received
a signal that the system's going down
I suppose the bash running the "loopmyprogram" script will get the kill
signal, as well and stop right away.
T
On 01/14/2014 12:07 PM, Mark Morgan Lloyd wrote:
You need to make sure that it doesn't try to restart if it's received
a signal that the system's going down
I suppose the bash running the "loopmyprogram" script will get the kill
signal, as well and stop right away.
-Michael
On 01/14/2014 12:10 PM, Michael Van Canneyt wrote:
Whether you launch a script or an actual program is entirely irrelevant.
We are discussing Linux, not Windows. So we will get what we expect :-) .
-Michael
___
fpc-pascal maillist - fpc-pascal@list
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:52 AM, Michael Van Canneyt wrote:
Of course it will wait. A script always waits till a command exits.
I see. Thanks (silly me).
In your init.d script you need launch the above script (call it
loopmyprogram) in the usual manner, i
Michael Van Canneyt wrote:
Does it exit in a sufficiently-controlled state that you could simply
exec a new copy at the end of the finalization block? The available
parameters should be accessible in /proc.
No need to modify the program. You can simply script it as
#!/bin/bash
while [ 1 ]; d
On 01/14/2014 11:52 AM, Michael Van Canneyt wrote:
Of course it will wait. A script always waits till a command exits.
I see. Thanks (silly me).
In your init.d script you need launch the above script (call it
loopmyprogram) in the usual manner, in the background.
Is there a more recommended "u
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:55 AM, Michael Van Canneyt wrote:
I had thought about introducing this when doing the implementation, but
decided against it.
Thanks for the warning.
You're welcome.
It also explains why I would go for the scripting solution. A
On 01/14/2014 11:55 AM, Michael Van Canneyt wrote:
I had thought about introducing this when doing the implementation,
but decided against it.
Thanks for the warning.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.fr
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:35 AM, Tony Whyman wrote:
Michael,
This should be a classic Unix program with two separate parent and child
processes, where the child process runs your program and the parent is
responsible for monitoring the child and respawning
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:32 AM, Michael Van Canneyt wrote:
#!/bin/bash
while [ 1 ]; do
yourprogram youroptions
done
I feel this will start multiple parallel copies of the program and not wait
until the previous one dies.
Of course it will wait.
A sc
On 01/14/2014 11:35 AM, Tony Whyman wrote:
Michael,
This should be a classic Unix program with two separate parent and child
processes, where the child process runs your program and the parent is
responsible for monitoring the child and respawning it when it stops.
The basic algorithm of the par
On 01/14/2014 11:32 AM, Michael Van Canneyt wrote:
#!/bin/bash
while [ 1 ]; do
yourprogram youroptions
done
I feel this will start multiple parallel copies of the program and not
wait until the previous one dies.
Moreover I understand that this loop will never exit. Hence I can't use
it a
On 01/14/2014 11:26 AM, Mark Morgan Lloyd wrote:
Does it exit in a sufficiently-controlled state
Yep. If nothing completely unexpected happens, it writes a message in a
log file and cleanly exits. Of course there _might_ be memory leaks, an
unexpected kill signal or other queer stuff that co
Michael,
This should be a classic Unix program with two separate parent and child
processes, where the child process runs your program and the parent is
responsible for monitoring the child and respawning it when it stops.
The basic algorithm of the parent is:
Begin
...
daemon(0,0):
..
repe
On Tue, 14 Jan 2014, Mark Morgan Lloyd wrote:
Michael Schnell wrote:
Hi Linux Experts.
Since years I am running an fpc program as a kind of daemon on a PC Linux
server.
I simply defined a "respawn" line in /etc/inittab and with any start of the
server, the program happily automatically r
Michael Schnell wrote:
Hi Linux Experts.
Since years I am running an fpc program as a kind of daemon on a PC
Linux server.
I simply defined a "respawn" line in /etc/inittab and with any start of
the server, the program happily automatically runs as a daemon.
I would appreciate any idea on
Hi Linux Experts.
Since years I am running an fpc program as a kind of daemon on a PC
Linux server.
I simply defined a "respawn" line in /etc/inittab and with any start of
the server, the program happily automatically runs as a daemon.
Now I migrated the the PC Linux server to an ARM based
19 matches
Mail list logo
