In elastic-agent rpm package is missing chkconfig dependency check

[michalpristas]

During systems migration to newer CentOS Stream version, they spotted one issue related to installation of elastic-package.
This package installs /etc/init.d/elastic-agent file but doesn't require chkconfig system package, which is supposed to provide /etc/init.d directory.

$ rpm -qf /etc/init.d/elastic-agent
elastic-agent-8.7.1-1.x86_64

$ rpm -qf /etc/init.d
chkconfig-1.19.1-1.el8.x86_64

As a result, if elastic-agent package is installed before chkconfig is installed, it creates /etc/init.d directory with wrong permission and then some subsequent rpm installation of other software fails:

error: unpacking of archive failed on file /etc/init.d: cpio: File from package already exists as a directory in system

Workaround the issue by explicitly installing chkconfig package before elastic-agent package

Is it possible to fix elastic-agent rpm to explicitly require chkconfig package?

More findings here:

it does work on stream 8
it does not work on Stream 9 and noticed that stream 9 is not in support matrix: https://www.elastic.co/support/matrix#matrix_jvm

Also in RHEL it does not work as chkconfig is NOT installed by default: https://access.redhat.com/solutions/6837271

This missing chkconfig dependency seems to be a problem for RHEL 9 as well which is supported in the matrix

Thanks you

[pchila]

Beats already dropped support for init.d with elastic/beats#41845 since the supported linux distributions use systemd.
Should elastic-agent drop support for init.d as well?
cc @ebeahan @nimarezainia @cmacknz

[ebeahan]

Looks like this was recently tried in #6174 but @cmacknz flagged a blocker due to bug reported in #6704.

Looks like there's consensus to drop support for init.d, but we need to reevaluate what needs done and the order.

[cmacknz]

Removing init.d might fix #6704 reading it again.

I'm not opposed to this, our default elastic-agent install creates a systemd service unit file, not an init.d script. I don't know of anywhere where we depend on init.d, the only recent issues are about us still creating init.d related directories on systems that use systemd.