[pve-devel] [PATCH cluster 1/6] remove unused sysv init.d service file

[Thomas Lamprecht]

On 11/14/2017 02:53 PM, Fabian Grünbichler wrote:
> On Mon, Nov 13, 2017 at 12:28:38PM +0100, Thomas Lamprecht wrote:
>> Signed-off-by: Thomas Lamprecht <t.lamprecht at proxmox.com>
>> ---
>>  debian/init.d              | 145 ---------------------------------------------
>>  debian/pve-cluster.default |  10 ----
>>  debian/rules               |   2 -
>>  3 files changed, 157 deletions(-)
>>  delete mode 100644 debian/init.d
>>  delete mode 100644 debian/pve-cluster.default
> 
> /etc/default/pve is used by the systemd unit as well..
> 

True that. Looking at it I would remove it there all together.
We use it to pass $DAEMON_OPTS variable to pmxcfs, which is empty per default.

pmxcfs accepts following options at the moment:

> 
> Usage:
>   pmxcfs [OPTION...]
> 
> Help Options:
>   -h, --help           Show help options
> 
> Application Options:
>   -d, --debug          Turn on debug messages
>   -f, --foreground     Do not daemonize server
>   -l, --local          Force local mode (ignore corosync.conf, force quorum)
> 

"help" can be safely ignored, as can "foreground" - it would break the service
as the Type is forking and thus systemd would expect that the starting process
returns rather quickly and kill it after the timeout thinking the start failed
when this is set.

Then there is "debug", while this is quite safe to use I do not expect to find
it in the wild. 1) it *spams* the logs in such a heavy manner that it's useless
for a user 2) if wished it can be enabled/disable on the fly by writing 1/0 to
/etc/pve/.debug (which is what we tell people in docs, et al. anyway)
So this parameter is also quite safe to ignore, IMO.

Then there is "local", now this can be enabled but is such evil and wrong so
that anybody setting it *permanently*, deserves to be saved by not allowing him
to do so. If somebody uses this we should hope that he did out of not knowing
better and is actually thankful when he learns what this meant.

Has anybody objections to this? It would be interesting to hear a reasonable
use case for this.

> I wonder if we should rm_conffile the init script for completeness sake?
> 

Would make sense to me.