3 ms·

#!/sbin/openrc-run depend() { need net } # Export some ENVs for it export SERVER_ADDRESS="0.0.0.0:8088" name="my-program" description="My program" comman

#!/sbin/openrc-run depend() { need net } # Export some ENVs for it export SERVER_ADDRESS="0.0.0.0:8088" name="my-program" description="My program" command="/usr/local/bin/my-program" # If it does not know how to background iself command_background=true pidfile="/run/${RC_SVCNAME}.pid" # To have logs output_log="/var/log/${RC_SVCNAME}.log" error_log="/var/log/${RC_SVCNAME}.err" It seems that it still uses Turing-complete shell scripts as configuration. Hard pass.

navi-desu 1y ago
what is... actually wrong with that? it works, it's extensible, and a simple service is just as declarative as systemd, but when you need to do something more complex (e.g. checking conditions before starting), you don't need to create a separate script to do so or pile up 10 ExecStartPre lines, just `start_pre() { ... }` away i've seen people again and again complain of "but shell scripts", while the default functions provide an interface with declarative variables right there, what is the actual issue with it?
- akdev1l 1y ago
  That it is a Turing complete language and now people can add all sorts of crazy logic I don’t want to have to evaluate a shell script to figure out how a system service is supposed to start
  - navi-desu 1y ago
    and how is that any different from system services doing `ExecStartPre=/usr/libexec/my_setup_script.sh`? or worse, 20 different `ExecStartPre` lines that basically build a shell script in the ini file, one line at a time services are not simply a set of knobs to start a single process, often they don't even have processes (e.g. wg-quick) and even when they do, it often involves setup, and sometimes cleanup. systemd has to provide the exact same functionality, even if they put a .ini-paint of coat in it -- the difference is that openrc doesn't make services install N helpers scripts for that. Really, "Not being turing complete" is a useless metric for "stopping complexity in init setups" the way you stop complexity is by giving pre-configured functionality that is easy to use. systemd did that very well, openrc does do that for a lot of things already, and we're adding more as we see the common need of init scripts for said features

navi-desu 1y ago

what is... actually wrong with that? it works, it's extensible, and a simple service is just as declarative as systemd, but when you need to do something more complex (e.g. checking conditions before starting), you don't need to create a separate script to do so or pile up 10 ExecStartPre lines, just `start_pre() { ... }` away i've seen people again and again complain of "but shell scripts", while the default functions provide an interface with declarative variables right there, what is the actual issue with it?

akdev1l 1y ago
That it is a Turing complete language and now people can add all sorts of crazy logic I don’t want to have to evaluate a shell script to figure out how a system service is supposed to start
- navi-desu 1y ago
  and how is that any different from system services doing `ExecStartPre=/usr/libexec/my_setup_script.sh`? or worse, 20 different `ExecStartPre` lines that basically build a shell script in the ini file, one line at a time services are not simply a set of knobs to start a single process, often they don't even have processes (e.g. wg-quick) and even when they do, it often involves setup, and sometimes cleanup. systemd has to provide the exact same functionality, even if they put a .ini-paint of coat in it -- the difference is that openrc doesn't make services install N helpers scripts for that. Really, "Not being turing complete" is a useless metric for "stopping complexity in init setups" the way you stop complexity is by giving pre-configured functionality that is easy to use. systemd did that very well, openrc does do that for a lot of things already, and we're adding more as we see the common need of init scripts for said features