Single instance systemd service won't start on Arch Linux

[hashworks]

Problem

Using a simple single instance configuration fails to start:

class { 'redis':
  daemonize      => true,
  unixsocket     => '/run/redis/redis.sock',
  unixsocketperm => '770',
}

systemctl status redis.service:

Feb 20 17:39:16 foo systemd[1]: Starting Advanced key-value store...
Feb 20 17:39:16 foo systemd[1]: redis.service: Failed with result 'protocol'.
Feb 20 17:39:16 foo systemd[1]: Failed to start Advanced key-value store.

This is because the Arch package uses ExecStart=/usr/bin/redis-server /etc/redis/redis.conf in the systemd unit file and expects supervised systemd in /etc/redis/redis.conf, which currently can't be set using the redis class.

Workaround

systemd::dropin_file { '10-supervised.conf':
  unit    => 'redis.service',
  content => @(EOT),
    # This file is managed by Puppet - DO NOT EDIT
    [Service]
    ExecStart=
    ExecStart=/usr/bin/redis-server /etc/redis/redis.conf --supervised systemd
    | EOT
}

Solution

Allow users to set supervised in the class.

[ekohl]

I noticed that Debian also doesn't set it in its unit file and uses Type=forking, at least in Debian 10. Then EL8 as Type=notify but passes --supervised systemd in ExecStart. We can't just set supervised systemd in redis.conf. I was thinking: should Archlinux instead be updated to set --supervised systemd in its unit file? That feels like the correct solution to me.

[hashworks]

You've got a point. Talked with the Arch package maintainer, he is going to adjust the unit file.

[ekohl]

Awesome! For what it's worth, Beaker recently learned to run on Arch (thanks @bastelfreak!). In #438 I found out there are more failures. It'd be great if we could get the acceptance tests to all pass so we can properly say it's supported.