1

Working on getting FreeRADIUS up and running and having issues adding to systemd.

Running standalone via radiusd -X works expected and all of the custom configurations are intact. Using freetds module to connect to MS SQL backend...

During compilation I set it to use "--with-systemd" but it did not add a service entry automatically or create a *.service file that I can find.

I tried using one found online without success. This results in a timeout error.

[Unit]
Description=FreeRADIUS high performance RADIUS server.
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/radiusd/radiusd.pid
ExecStartPre=-/bin/chown -R freerad:freerad /var/run/radiusd
ExecStartPre=/usr/local/sbin/radiusd -C
ExecStart=/usr/local/sbin/radiusd -d /usr/local/etc/raddb
ExecReload=/usr/local/sbin/radiusd -C
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Has anyone successfully added a compiled version of FreeRADIUS (3.0) to systemd? If so, can you give some guidance on how to get this working?

Thanks.

Arnydo
  • 13
  • 1
  • 6

1 Answers1

1
  1. The configure option "with-systemd" adds support of the systemd watch dog, but not includes the systemd unit file. If you don't sure, what you need it, don't enable this option.
  2. Try to diagnostize what happens. Start from systemctl status freeradius. What has it shown?
  3. Here is standard the systemd unit file from the freeradius package. Copy it into /etc/systemd/system/freeradius.service and change the pathes. It will the start point.
# /lib/systemd/system/freeradius.service
[Unit]
Description=FreeRADIUS multi-protocol policy server
After=network.target
Documentation=man:radiusd(8) man:radiusd.conf(5) http://wiki.freeradius.org/ http://networkradius.com/doc/

[Service]
Type=forking
PIDFile=/run/freeradius/freeradius.pid
EnvironmentFile=-/etc/default/freeradius
ExecStartPre=/usr/sbin/freeradius $FREERADIUS_OPTIONS -Cxm -lstdout
ExecStart=/usr/sbin/freeradius $FREERADIUS_OPTIONS
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Update from comments

  1. The systemd support in the freeradius includes some features:

    • Notification about completion of start-up
    • The systemd watchdog support to prevent the hunging up.

  2. The best aproach is:

    • Use this hardened service unit for freeradius. Change the pathes to yours.
    • Pass the -f option to the freeradius to prevent forking. If you use the service unit flle from link above, you should add -f into /etc/sysconfig/radiusd. Some discussion about it you can read here. The forking is the legacy way to deamonize. Today a demonization at start of program can be delegate to special programs like systemd or start-stop-daemon.
    • Use Type=notify in the service section of the unit file.
Anton Danilov
  • 4,874
  • 2
  • 11
  • 20
  • 1
    This unit file looks a bit strange. Is it from Debian/Ubuntu? – Michael Hampton Jun 05 '19 at 17:46
  • I didn't find much documentation on --with-systemd so I assumed it setup to run as a service. I added the unit file as you recommended and had the following result: Jun 05 14:00:42 freeradius systemd[1]: freeradius.service: PID file /run/freeradius/freeradius.pid not readable (yet?) after start: No such file or directory – Arnydo Jun 05 '19 at 18:01
  • You can just comment the `PIDFile` option and try again. Also, check what the `/run/freeradius` directory exists. – Anton Danilov Jun 05 '19 at 18:22
  • For some reason it is not allowing the user radiusd to create the PID file (even if commented out in Unit file its still going to try and create the PID). Failed creating PID file /usr/local/var/run/radiusd/radiusd.pid: Permission denied I verified that the user/group radiusd:radiusd is owner of the /usr/local/var/run/radiusd/ folder – Arnydo Jun 05 '19 at 20:38
  • The pid file is created by freeradius itself. The systemd just tries to find the pid file, specified with `PIDFile` option to monitor state of the freeradius daemon. So, you should check the options of the freeradius. – Anton Danilov Jun 05 '19 at 20:58
  • 2
    That unit file is definitely from our ubuntu packages. The centos/rhel one uses more standard paths, and the one from master branch has additional hardening - https://github.com/FreeRADIUS/freeradius-server/blob/master/redhat/radiusd.service As for the permission issue, i'd start another question for that. Anton has done a good job of answering this one, it should be accepted and closed. – Arran Cudbard-Bell Jun 06 '19 at 00:35
  • 2
    One thing though, if you switch out the service type to notify, build with systemd support, and pass the '-f' flag to the daemon, I think that'll fix your issue. I believe 'notify' does not expect the daemon to fork, and passing -f will make freeradius run in foreground mode, and not drop a PID. There's some discussion here: https://github.com/FreeRADIUS/freeradius-server/pull/2698 – Arran Cudbard-Bell Jun 06 '19 at 01:01
  • 1
    @ArranCudbard-Bell That's the proper answer, running the service in `Type=notify` is the best approach. `Type=forking` is meant for backwards compatibility, it's not ideal (it's a hack) and should be avoided whenever possible. You also linked to a nice `.service` file as base. You should turn this into an answer. – filbranden Jun 06 '19 at 03:13
  • +1 for your comment @ArranCudbard-Bell. If you add this as an answer I think it should have the best answer. – Arnydo Jun 06 '19 at 18:32