SDP-837
Open
Make force_start in p4d_N_init easier with systemd.
The 'force_start' option to p4d_N_init scripts (coded in p4d_base) is
easy to use when only raw SDP init scripts are used. That is, one can
run 'p4d_1_init force_start' just as easily as 'p4d_1_init start'.
Even the safety feature requiring systemctl to be used can be bypassed
by calling the underlying init script with the force_start option.
However, when systemd init scripts are used, as is typical in 2022,
utilizing the force_start option while still using systemctl requires
root access and familiarity with systemd to edit the systemd *.service
file(s) for p4d, and then doing a 'systemctl daemon-reload' before
restarting the service. Later, these steps must be undone when force
starts are no longer required.
Implementation Goals:
* Avoid modifying the systemd *.service files, as changes to these
require an update to the install mechanism. While possible, this is
discouraged.
Suggested Implementation:
* Provide a second method of specifying a force start should be done,
by touching a file /p4/N/bin/force_start.
* Modify the p4d_base to check for existence of the force_start file,
and if detected, behave as if 'force_start' had been used instead of
start.
* Make no changes to the systemd *.service file templates.
Digression: Passing parameters to scripts called in systemd *.service
files directly is not supported by systemd. It's possible with creative
workarounds using the Environment field to read in settings from a file.
For our purpose, a 'touch file' is all that is needed.
Also: Document the intent of the force start option, and potential risks
of using it. Without force_start, the init scripts refuse to start p4d
if the databases in P4ROOT fail a 'p4d -xvU' safety check, indicating
possible database corruption.
The 'force_start' option to p4d_N_init scripts (coded in p4d_base) is
easy to use when only raw SDP init scripts are used. That is, one can
run 'p4d_1_init force_start' just as easily as 'p4d_1_init start'.
Even the safety feature requiring systemctl to be used can be bypassed
by calling the underlying init script with the force_start option.
However, when systemd init scripts are used, as is typical in 2022,
utilizing the force_start option while still using systemctl requires
root access and familiarity with systemd to edit the systemd *.service
file(s) for p4d, and then doing a 'systemctl daemon-reload' before
restarting the service. Later, these steps must be undone when force
starts are no longer required.
Implementation Goals:
* Avoid modifying the systemd *.service files, as changes to these
require an update to the install mechanism. While possible, this is
discouraged.
Suggested Implementation:
* Provide a second method of specifying a force start should be done,
by touching a file /p4/N/bin/force_start.
* Modify the p4d_base to check for existence of the force_start file,
and if detected, behave as if 'force_start' had been used instead of
start.
* Make no changes to the systemd *.service file templates.
Digression: Passing parameters to scripts called in systemd *.service
files directly is not supported by systemd. It's possible with creative
workarounds using the Environment field to read in settings from a file.
For our purpose, a 'touch file' is all that is needed.
Also: Document the intent of the force start option, and potential risks
of using it. Without force_start, the init scripts refuse to start p4d
if the databases in P4ROOT fail a 'p4d -xvU' safety check, indicating
possible database corruption.
- Status
- Open
- Project
- perforce-software-sdp
- Severity
- C
- Reported By
- Perforce maintenance
- Reported Date
- 2 years ago
- Modified By
- C. Thomas Tyler
- Modified Date
- 2 years ago
- Owned By
- perforce
- Component
- core-unix
- Type
- Feature
See: