[xerxes901]

> As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does)

Depending on what you want to do, a generator might be appropriate:

> Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins

[simoncion]

Well, here are the relevant parts of the service file:

  get_config() {
      [ -f "${PGDATA%/}/postgresql.conf" ] || return 1
  
      eval echo $(sed -e 's:#.*::' "${PGDATA%/}/postgresql.conf" \
          | awk '$1 == "'$1'" { print ($2 == "=" ? $3 : $2) }')
  }
  
  depend() {
      use net
      provide postgresql
  
      if [ "$(get_config log_destination)" = "syslog" ]; then
          use logger
      fi
  }

If PostgreSQL has been configured, this reads its config file, looks to see if it's configured to use 'syslog' as its log destination, and -if so- adds a dependency on the 'logger' "meta-service". [0]

What would this look like with a systemd service file generator?

[0] What's a "meta-service"? 'provide postgresql' makes the service started by this service file provide the 'postgresql' "meta-service". This is useful for PostgreSQL because you can install multiple versions of the software simultaneously... so the service files are named like postgresql-17, and postgresql-18. The 'logger' "meta-service" is useful because who cares which syslog software you have installed... you only care that it speaks syslog.

[xerxes901]

Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations etc is… not a great idea in my opinion.

But of course in this particular case, because systemd makes the /dev/log journal/syslog socket a dependency of every unit by default, there is no need to encode this dependency at all.

Anyway if you really wanted to you could write this script as a generator and have it put a drop-in in /run/systemd/system/postgres.service.d. But… why?

[simoncion]

Okay, I'll rephrase the question a bit and ask it again.

Imagine that you have a service that has a configuration-dependent dependency on rsyslog. For whatever reason, journald's not an option... maybe it's simply not installed, or this service depends on rsyslog-specific behaviors that journald simply doesn't replicate. It doesn't matter why this configuration-dependent dependency exists, it simply exists and there's no workaround.

Assuming that the rsyslog service is named 'rsyslog', the service with the dependency is named 'stupid-service', the configuration file is named '/etc/stupid-service/stupid-service.conf', and the configuration option to search that config file for is 'logging = syslog', what would the systemd service file generator look like to make 'stupid-service' depend on 'rsyslog' if and only if that config file contains 'logging = syslog'?

You appear to have worked with these service file generators, which is why I'm asking. I expect you'd know what the generator to accomplish this trivial task would look like, or if it was even possible with generators.

Also:

> Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations

Nah, this is substring matching and column-cutting. The only use of regexes ("#.*") is to remove comments. Go check out the format docs for the PostgreSQL config file. [0] It's pretty basic and straightforward.

[0] <https://www.postgresql.org/docs/17/config-setting.html#CONFI...>

[xerxes901]

Put a script in /etc/systemd/system-generators/ that does something like

  if grep "logging = syslog" /etc/stupid-service/stupid-service.conf >/dev/null; then
    printf "[Unit]\nAfter=rsyslogd.service\n" > "$1/stupid-service.d/10-syslog-dep.conf";
  fi;

> It's pretty basic and straightforward

Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; it could potentially match a file just because some other option contained a multi-line value that had the string "log_destination = syslog" in it.

The whole philosophy of systemd is to move away from these kinds of "simple" and "mostly working" pile-of-shell-script systems to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.

[simoncion]

> Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; ...

Where's that documented?

I tried the obvious things followed by a config reload. Here are the results (the 'log_destination' parameter is on line 482 of the config file):

  log_destination = \
   'stderr'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "\"
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'stderr'"
  LOG:  configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
  

  log_destination = 'std
  err'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
  LOG:  configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied

  log_destination = 'std\
  err'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
  LOG:  configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied

  log_destination = 'stderr'
  
  LOG:  received SIGHUP, reloading configuration files
  <No additional output is produced because 'stderr' is the default>
  
  #log_destination = 'stderr'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  parameter "log_destination" removed from configuration file, reset to default

What's the line continuation character for 'postgresql.conf'? Are you certain that you're not getting 'postgresql.conf' confused with 'pg_hba.conf'? That file is documented to support line continuations: [0]

  The general format of the pg_hba.conf file is a set of records, one per line. Blank lines are ignored, as is any text after the # comment character. A record can be continued onto the next line by ending the line with a backslash. (Backslashes are not special except at the end of a line.) 

> The whole philosophy of systemd is to move ... to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.

That's truly a lovely and laudable goal. In this system, how does you propose one processes a flat text config file with a mix of 'K = V' and 'K V' settings without doing ordinary, boring text processing? Do you propose that one waits until "systemd-configd" gets created and every daemon of any importance is updated to put its config in there instead of in flat files? If so, has there been any notable progress on this in the last ~fifteen years?

> Put a script in /etc/systemd/system-generators/...

Thanks for finally answering my question. Is the way to conditionally update service dependencies really to dump text files in magic locations? Is there no 'systemctl' (or similar) command that allows one to manipulate dependencies for a specific service that one can call from a generator?

[0] <https://www.postgresql.org/docs/17/auth-pg-hba-conf.html>