Hi guys, question about osqueryd. osqueryd seems ...
# general
j
Hi guys, question about osqueryd. osqueryd seems to depend on SysV to be enabled (chkconfig package is required to be installed), however it starts just fine. This doesn't really make sense to me. osquery should be able to be enabled through systemd if it can be started through systemd. Does anyone know why this is the case? Is this a potential bug or is there a workaround? I would prefer to not use SysV.
[jordan ~]$ sudo systemctl enable osqueryd
Synchronizing state of osqueryd.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable osqueryd
Failed to execute /usr/lib/systemd/systemd-sysv-install: No such file or directory
[jordan ~]$ sudo systemctl start osqueryd
[jordan ~]$ sudo systemctl status osqueryd
● osqueryd.service - The osquery Daemon
Loaded: loaded (/usr/lib/systemd/system/osqueryd.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2022-06-22 09:55:31 UTC; 5s ago
s
I’m not deeply familiar with the current linux init systems, but this seems weird. What operating system? What package did you install? Where did it come from?
j
installed on Fedora 34. Install process -
sudo curl -L <https://pkg.osquery.io/rpm/GPG> | sudo tee /etc/pki/rpm-gpg/RPM-GPG-KEY-osquery; sudo dnf config-manager --add-repo <https://pkg.osquery.io/rpm/osquery-s3-rpm.repo>; sudo dnf config-manager --set-enabled osquery-s3-rpm-repo; sudo dnf install osquery
s
I was trying on Ubuntu too. The issue seems to be that since we still install both a native service file and an init script with the same name, systemd detects both and
enable
or
disable
commands work on both. Although the issue is slightly different, for instance this bug report briefly mentions it: https://github.com/systemd/systemd/issues/15394 I'm not sure if there's a way to ask systemd not to do that, or if we should just not ship an init script anymore. Although for RPM based distros, we still support CentOS 6 which doesn't have systemd. Maybe what we could do is to not install the service file or init script in the system, but leave them as an example on the side under the
/opt
folder. Then the user would've to choose what to use.
👍 1
I mean I know that there's the alternative of preparing 2 packages each with their own choice, but that adds to the maintenance
s
TBH I always feel like it’s weird we ship packages, but 🤷 that ship sailed.
If we thought most users wanted systemd, we could bake that into the rpms, and ship the init script in some doc directory. I think that’s pretty common?
Or ship them both as optional, and try to guess and install in a postinstall script?
j
would it be worth it to open this as a bug on GH? @Stefano Bonicatti I think it makes sense to give the choice to the user. As you mentioned CentOS 6 doesnt support systemd and Fedora has not supported SysV for a while now.
s
@Jordan yeah I would track this as an issue. I think though that as seph was suggesting, we can detect what the system is running (https://www.freedesktop.org/software/systemd/man/sd_booted.html describes that internally just does a check for the existence of a folder, something we can easily do in a postinstall)
👍 1