1 |
Alan McKinnon <alan.mckinnon@×××××.com> writes: |
2 |
|
3 |
> On Friday 26 February 2010 23:44:03 Harry Putnam wrote: |
4 |
>> Where I'm weak is the part where the custom script checks if the |
5 |
>> daemon is running, before the script itself starts. That part would |
6 |
>> need to be something pretty fool proof... maybe just grep ps output |
7 |
>> for the daemon? |
8 |
> |
9 |
> Maybe I'm misunderstanding you, but I don't understand this approach. |
10 |
> |
11 |
> If the daemon is not running there's nothing in the fifo. Why got to all the |
12 |
> complexity of writing an independent program that checks if something is |
13 |
> running then does various actions? The script necessarily depends on the |
14 |
> daemon running so instead of checking if it is, simply have the daemon start |
15 |
> the script. No daemon running = no script launched = no complexity. |
16 |
|
17 |
In the back of my mind there was a reason on opensolaris, that the |
18 |
script would fail if the fifo was empty... Then once data comes the |
19 |
script isn't listening. Or syslog won't write or something similar. |
20 |
|
21 |
I also have an opensolaris box that will be using this same script. |
22 |
|
23 |
I don't want to back up and relocate all that right now... Not sure I |
24 |
have it remembered right either, it seems just easier to have the |
25 |
script check before trying to start (for portability). |
26 |
|
27 |
Solaris syslog can write to named pipes but no so readily as linux |
28 |
syslog. Not sure of the details now. |
29 |
|
30 |
> If I'm still off-bat and this approach cannot work for solid technical |
31 |
> reasons, then I'll go away and shut if if you say so :-) |
32 |
|
33 |
No, not off-base... thanks. The checking isn't so hard to figure |
34 |
anyway, but you didn't talk about the script having some kind of trap |
35 |
or something to cover unexpected kill or failure. |
36 |
|
37 |
Michael has covered that somewhat. |
38 |
|
39 |
Also I didn't think to search cpan for something that does what I |
40 |
want. That may turn up something I can just plug into. |
41 |
|
42 |
Michael Higgins <linux@×××××××.org> writes: |
43 |
|
44 |
[...] |
45 |
|
46 |
> in my perl script: |
47 |
> |
48 |
> log_file=>'Sys::Syslog', pid_file=>'/var/run/evolone_agi.pid'; |
49 |
> |
50 |
> Sys::Syslog" is an interface to the UNIX syslog(3) program. |
51 |
> |
52 |
> from /etc/init.d/evolone_agi |
53 |
> |
54 |
> depend() { |
55 |
> need net asterisk postgresql-8.4 |
56 |
> } |
57 |
> |
58 |
> As for reading new information, there are a gazillion ways. Trap a |
59 |
> signal to reread the configs? |
60 |
> |
61 |
> reload() { |
62 |
> ebegin "Reloading evolone_agi configuration" |
63 |
> start-stop-daemon --signal 1 --pidfile /var/run/evolone_agi.pid |
64 |
> eend $? "Error reloading evolone_agi" |
65 |
> } |
66 |
|
67 |
Thanks ... good info. How does the script behave regarding what |
68 |
happens if it receives a sigINT or sigKILL, or some other way dies |
69 |
(even from an internal error)? |
70 |
|
71 |
Does it log to syslog? and notify sysadmin? |
72 |
|
73 |
I haven't had occasion to run into an `EXIT trap' in perl... but there |
74 |
must be such a thing. |