Freeradius systemd radiusd.service fails
Hi everyone, We currently using freeradius version 3.0.11 and it is compiled to work with oracle db and everything is fine and smooth when running the service using radiusd -X or radiusd. Once we start the service using systemctl start radiusd.service or systemctl restart radiusd.service then we receive the below error: "Job for radiusd.service failed because the control process exited with error code. See "systemctl status radiusd.service" and "journalctl -xe" for details." We figured out that the sql module in the mods-enabled is causing the service to not start using the systemctl start radiusd.service. As soon as we remove the sql linked file from the mods-enabled, we surprisingly are able to run the systemctl command! We checked many articles about this error, some users mentioned this is a file permission issue. We tried to change the sql module permission to root.root or root.radiusd but all was failing. Any ideas? Thank you --
On Tue, Mar 15, 2016 at 2:27 PM, Ibrahim Almahfooz <ibrahim.nezar@gorannet.net> wrote:
Hi everyone,
We currently using freeradius version 3.0.11 and it is compiled to work with oracle db and everything is fine and smooth when running the service using radiusd -X or radiusd.
Once we start the service using systemctl start radiusd.service or systemctl restart radiusd.service then we receive the below error:
"Job for radiusd.service failed because the control process exited with error code. See "systemctl status radiusd.service" and "journalctl -xe" for details."
What does "systemctl status radiusd.service" and "journalctl -xe" say? It should tell you what it thinks is wrong. One possibility is that oracle depends on $ORACLE_HOME env variable, which is present when you log in as root/normal user, but not available when started by systemd. If that's the case, use Environment or EnvironmentFile inside the systemd unit. Look at your existing systemd unit files (e.g. ssh.service) for example. -- Fajar
On 15/03/2016, at 21:44, Fajar A. Nugraha <list@fajar.net> wrote:
On Tue, Mar 15, 2016 at 2:27 PM, Ibrahim Almahfooz <ibrahim.nezar@gorannet.net> wrote:
Hi everyone,
We currently using freeradius version 3.0.11 and it is compiled to work with oracle db and everything is fine and smooth when running the service using radiusd -X or radiusd.
Once we start the service using systemctl start radiusd.service or systemctl restart radiusd.service then we receive the below error:
"Job for radiusd.service failed because the control process exited with error code. See "systemctl status radiusd.service" and "journalctl -xe" for details."
What does "systemctl status radiusd.service" and "journalctl -xe" say? It should tell you what it thinks is wrong.
One possibility is that oracle depends on $ORACLE_HOME env variable, which is present when you log in as root/normal user, but not available when started by systemd. If that's the case, use Environment or EnvironmentFile inside the systemd unit. Look at your existing systemd unit files (e.g. ssh.service) for example.
Another thing to check is your selinux config. Services started under systemd can get more/less permissions than you expect. Watch /var/log/audit/audit.log when you start it. You might also try disabling selinux (setenforce 0) temporarily to test. You should write a policy that does what you want if you prove that selinux is the problem though, rather than disabling it. It’s not too difficult. -- Nathan Ward
Read the output of those 2 commands it gives you (really, systemd does try to help you! ) . Ensure that the permissions of all files in raddb config are correct - owned by and readable by the user/gtoup that radiusd runs as. Ensure that all log/other locations are the same. If your module requires other environment variables ensure that those are in the startup scripts. Finally. If using selinux et al , check those audit logs to see if the system believes that the daemon has no right to connect to certain ports etc and fix those issues (LOTS of people using postgres/mariadb etc so those systems are pretty well covered but oracle is rare and distro operators, for example, will not have provided patches/fixes/updates to deal with it) alan
participants (4)
-
Alan Buxey -
Fajar A. Nugraha -
Ibrahim Almahfooz -
Nathan Ward