>From the prospective of someone who has written many init
scipts/mechanisms, I will say there is never going to be one script to
start, stop, and manage everything. For example, I recently learned
that FreeBSD does not have a /proc system mounted by default, a script
command that uses 'ps -ef' does not work. Some programs spawn threads,
some use a pid file, sometimes the pid will be in different places,
some programs change their display name, (I never liked that), some
have a management port, etc, some programs even respond to standard
signals wrong.
Having a nice generic script is always a good base point. With the
80/20 rule the 'anything' script would work well most of the time, if
you were to start adding attributes to account for special cases it
would get over-designed.
I have found that init scripts in general are a lost art form. Often I
find that init scripts do not follow the LSB conventions or return the
wrong int code or display the wrong output. Some of them have logic
that falls apart if you are running more then one instance of program
X. If you are lucky enough to find an init script. I'm on a tangent.
Anyway I think the world needs more RA's and init scripts. Keep up the
good work.
On Tue, Jun 17, 2008 at 1:06 PM, Serge Dubrouski <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2008 at 10:34 AM, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote:
>> Hi Dominik,
>>
>> On Tue, Jun 17, 2008 at 11:28:17AM +0200, Dominik Klein wrote:
>>> Hi
>>>
>>> I wrote an RA, which can start virtually anything in a very basic meaning.
>>
>> An interesting idea :)
>>
>>> You can configure
>>> * binfile
>>> * cmdline_options
>>> * logfile
>>> * errlogfile
>>> * user
>>>
>>> Names should be self-explaining I guess.
>>>
>>> The RA starts the command configured with $binfile and $cmdline_options
>>> as $user and redirects stdout and stderr to appropriate files.
>>
>> This may not be necessary. Whatever comes out on stdout/stderr
>> will be logged by lrmd.
>>
>>> It stops the command with kill. If kill does not work, it uses kill -9.
>>
>> I guess that you mean kill without options which translates to
>> kill -TERM.
>>
>>> Monitors are done with ps. No deep check here but a pointer where to
>>> implement that if needed.
>>
>> Perhaps implement a monitor script hook, such as the one in Xen.
>> That way one keeps the RA intact.
>
> It would be good to have one more optional parameter: monitor_script.
> In this case user would be able to provide his own monitor and that
> would create more flexibility.
>
>>>
>>> anything_stop() {
>>> if anything_status
>>> then
>>> tries=5
>>> i=0
>>> while [ $i -lt $tries ]
>>> do
>>> # there may be programs without command line options
>>> [ -n "$cmdline_options" ] && cmd="$binfile
>>> $cmdline_options" || cmd="$binfile"
>>> pkill -u $user -f "$cmd"
>
> I personally don't like the idea of relying on the fact that binfile
> will start a process with the same name. One could have a custom
> script for starting a process with other name. On other hand one could
> also have several processes with the same name.
>
>
>
> --
> Serge Dubrouski.
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
