davmac314 / dinit

Service monitoring / "init" system
Apache License 2.0
582 stars 45 forks source link

Help for an Ansible Module #341

Closed migmolrod closed 3 months ago

migmolrod commented 3 months ago

I'm trying to write an Ansible module to be able to manage dinit services. To make it idempotent, I have to check if a given service is running or not (easy) and also if it's enabled or not (this is my question).

Can we assume that, if the service name I pass as parameter to my module exists in the /etc/dinit.d/boot.d as a symlink, it's "enabled"? Or is there a better way to know it, using dinitctl? I've read dinitctl --help but couldn't find it.

davmac314 commented 3 months ago

Probably for your purposes checking for the symlink in /etc/dinit.d/boot.d is fine (though it's not universally correct, eg if that directory isn't specified via a waits-for.d = in the boot service description). There's no currently supported way to simply check if a service is enabled or not.

Note also that a service that isn't specifically "enabled" might still run at startup, if it is a dependency of another (enabled) service for example.

migmolrod commented 3 months ago

I see. Thanks for your help.

For the first part, I don't know how common is to have a different boot.d folder in the boot service description. But maybe I can try and read it from there. I found it in /etc/lib/dinit.d/boot. Can this be just my distro, and other distros install it in a different place?

But anyways, another approach I've found is to use returncode and stderr. I'm using python (apparently is a very common language to develop Ansible modules, but I don't like it too much, honestly) and I think I can run a command and somehow store the return code, the stdout, the stderr and so on.

And I've noticed that dinitctl enable/disable <servicename> returns the usual 0 if everything goes ok (considered a "change" in terms of idempotency) and 1 if something goes wrong. That includes that the service is already enabled/disabled and no change will be made. I can capture that case and consider it a "skip" in terms of idempotency, not an actual "error". And then catch the rest of possible errors to return them so the user can see what went wrong. I think that includes that the specified service does not even exist and also permission errors, like non-root users wanting to enable/disable system services and such.

It's way harder that stat a file but maybe it's better.

For the second part, that's interesting. I have to define what I think the user wants to really do if they enable, for instance, the swap service. Which is running (again, in my distro at least, don't know if others handle it differently) by default because it's, in the dependency tree, below something that starts on boot. I'll have to think about that. Because can be quite cumbersome to check the entire dependency tree to see if any of its parents is already "enabled" (ie, in the boot.d folder) or not.

Or I don't know. Maybe I'll end up making a module that just works in my distro and don't publish it. Or, if I publish it, put a gigantic disclaimer.

Thanks again. I think this can be closed.