PP-660: Add support to PBS init script to act on any PBS daemon individually


#1

Hi @developers,

Please review a new design change to enhance PBS init script to start/stop/restart/status individual PBS daemons. Currently these actions are done on all daemons together.

https://pbspro.atlassian.net/wiki/display/PD/PP-660%3A+Add+support+to+PBS+init+script+to+act+on+any+PBS+daemon+individually
Please do let me know of any comments or suggestions.

Thanks,
Sarita


#2

Hello Sarita, a few initial comments:

  1. I’d think we’d concentrate on adding this functionality to the systemd unit file rather than the init scripts since while we currently support non-systemd systems (RHEL 6 , SLES 10, CentOS 6), systemd systems are clearly the future of our supported platforms. In reality it is all tied together behind the scenes, at least today the pbs.service unit file ultimately calls /opt/pbs/libexec/pbs_init.d, which is the same as the init script that ends up in /etc/init.d, but that may not always be the case so the design should be written either generically or with specific interfaces for systemd unit files. Syntax examples of how this would be used with systemctl also need to be included.

  2. The EDD currently says “The existing behaviour would be the same of init script”, I assume that means that the actual method (qterm, kill, etc.) of stop or starting (pbs_mom with no -p, etc.) the daemon would be the same, correct? If so, I think it should be a bit more explicit about this.


#3

Could you change “as done currently” to “as done by default”.
Please also elaborate what do you mean by “The existing behaviour would be the same of init script”. How are you planning to start|stop|restart single daemon as qterm also kills server if you give -s or -m.


#4

Could you explain why the restart interface should be restricted to restarting only a single service? Why shouldn’t we be able to (e.g.) restart both server and scheduler with a single command-line invocation?


#5

@saritakh, why are we supporting only a single daemon name. Code wise, I believe we can support two daemon names as well. Not sure if such a use case will be useful.

However, if we support or not multiple daemon names, the proposed design should specify if there are any new error or notification messages that the script will output.