I would not be opposed to this patch, any other opinions?

Sounds sensible to me.

I will defer to the administrators who use this. I do not use init.d to start
the server. But I do not see any problems at first glance to add a create
option. The create looks for an existing serverdb and does not overwrite it. It
would only be useful if a serverdb does not exist.

With the addition of the -d $PBS_HOME to the pbs_server startup, the "create"
operation has become far less dangerous than it was when dbeer originally
commented it out.  It seems to me that maybe, in addition to adding a "create"
option, create should still be the default if no serverdb is present in
$PBS_HOME.

I'm a big fan of getting as close to working-out-of-the-box as possible, and
automatic creation of a basic configuration when nothing exists is a good means
to that end, IMHO.

I can create an alternative patch that crystallizes my thoughts if others
agree.

Created an attachment (id=64) [details]
The Scyld ClusterWare shipped version

You might find the init script we use with Scyld to be a bit more complete. It
also includes things like (configure) and (reconfigure). Though the
config-nodes action used some Scyld Specific stuff and probably should be
stripped out.

-Josh

(In reply to comment #5)
> You might find the init script we use with Scyld to be a bit more complete. It
> also includes things like (configure) and (reconfigure). Though the
> config-nodes action used some Scyld Specific stuff and probably should be
> stripped out.

IMHO, this script would take a LOT of work to make usable.  It violates several
principles of init scripts (such as not calling other init scripts and sourcing
external configuration) and makes numerous assumptions about the cluster
configuration.

I saw a couple ideas in this script that might be good to add in to the
existing init script, but starting with this one would take far more work.

One of the motivations for not doing a create within the start method when
the db does not exist is the following.

# rm -f /var/lib/torque/server_priv/serverdb
# /etc/init.d/pbs_server start
Starting TORQUE Server:                                    [  OK  ]

Of course we just created the serverdb at this point.

# pgrep -fl pbs_server
30282 /usr/sbin/pbs_server -t create

To me it some how seems a bit messy to leave the process running with
this extra "-t create" the first time.

It just seems a bit inconsistent somehow to start the service in a different
way depending on the starting state.

Steve.

Created an attachment (id=65) [details]
Proposed init script patch

Here's a possible patch which would take your concerns into account as well as
mine.  Thoughts?

(In reply to comment #8)
> Created an attachment (id=65) [details] [details]
> Proposed init script patch
> 
> Here's a possible patch which would take your concerns into account as well as
> mine.  Thoughts?

If no one is screaming, "NO!" does that imply a "Yes?"  :-)

This is to second Michael's call for comment. Please review the patch and let
us know if there are any objections. If now we will submit this to the build.

Ken Nielson

One thought on the create option - currently it just blows any existing DB
away.

My suggestion is for it to check if one exists and if so warn the admin and ask
them to remove it, then exit with a non-zero value.

Just in case...

(In reply to comment #11)
> One thought on the create option - currently it just blows any existing DB
> away.
> 
> My suggestion is for it to check if one exists and if so warn the admin and ask
> them to remove it, then exit with a non-zero value.
> Just in case...

Yes that would be my preference also, make it hard to do damage.

Steve.

(In reply to comment #11)
> One thought on the create option - currently it just blows any existing DB
> away.
> 
> My suggestion is for it to check if one exists and if so warn the admin and ask
> them to remove it, then exit with a non-zero value.

It is not permissible for an init script to ask questions.

Besides, if you read up, Ken already said that "create" will not overwrite an
existing DB.  So what's the problem here?

Created an attachment (id=70) [details]
Updated proposed patch

This new patch contains all the previous changes and adds the ability to
specify additional arguments to pbs_server in the /etc/sysconfig/pbs_server
file.  This allows an admin to, for example, set PBS_ARGS="--ha" in the
aforementioned file and have it persistent across reinstalls of the torque
RPM's.  Previously one had to edit the init script directly, and those changes
would be overwritten by newer torque packages (since the init script is not
marked as a config file, nor should it be).

If anyone is opposed to either or both changes, please speak up.

(In reply to comment #14)
> Created an attachment (id=70) [details] [details]
> Updated proposed patch
> 
> This new patch contains all the previous changes and adds the ability to
> specify additional arguments to pbs_server in the /etc/sysconfig/pbs_server
> file.  This allows an admin to, for example, set PBS_ARGS="--ha" in the
> aforementioned file and have it persistent across reinstalls of the torque
> RPM's.  Previously one had to edit the init script directly, and those changes
> would be overwritten by newer torque packages (since the init script is not
> marked as a config file, nor should it be).
> 
> If anyone is opposed to either or both changes, please speak up.


I like the changes

@Michael - I wasn't proposing that the script ask a question, just tell the
user the DB has already been initialised if it exists.

Currently your changes will just blow any existing configuration away as it
does not test for its existence (unless I'm missing something).

Created an attachment (id=71) [details]
Updated proposed patch

Updated patch to check for serverdb and fail create() if present

Thanks Michael, the change to create looks good to me!

One query - any reason to use killproc rather than qterm -t quick ?

This patch has been added to TORQUE 2.5-fixes, 3.0-fixes and trunk