Comment by hparadiz

2 days ago

OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on.

OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.

There are growing pains. https://bugs.gentoo.org/936123

Especially when upstream hard requires systemd. More annoying when there's no real reason for it.

But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.

7 comments

hparadiz

Reply
simoncion  1 day ago

To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]:

  #!/sbin/openrc-run
  
  command="/usr/bin/rsync"
  command_args="--daemon ${RSYNC_OPTS}"
  pidfile="/var/run/${SVCNAME}.pid"
  
  depend() {
   use net
  }

Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs.

Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]

[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.

[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).

  • xerxes901  19 hours ago

    > 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  17 hours ago

      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.

      4 replies →