​Re: Freeradius systemd radiusd.service fails

[Ibrahim Almahfooz]

​>
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.

​I really appreciate you help Fajar. It is solved by setting the enviroment
variable on the systemd radiusd.service

Thank you very much! ​

On 15 March 2016 at 14:00, <freeradius-users-request at lists.freeradius.org>
wrote:

> Send Freeradius-Users mailing list submissions to
>         freeradius-users at lists.freeradius.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.freeradius.org/mailman/listinfo/freeradius-users
> or, via email, send a message with subject or body 'help' to
>         freeradius-users-request at lists.freeradius.org
>
> You can reach the person managing the list at
>         freeradius-users-owner at lists.freeradius.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freeradius-Users digest..."
>
>
> Today's Topics:
>
>    1. Re: Freeradius systemd radiusd.service fails (Fajar A. Nugraha)
>    2.
> ​​
> Re: Freeradius systemd radiusd.service fails (Nathan Ward)
>    3. Re: Freeradius systemd radiusd.service fails (Alan Buxey)
>    4. Network Design - FreeRadius (Richard J Palmer)
>    5. Re: Network Design - FreeRadius (Arran Cudbard-Bell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Mar 2016 15:44:04 +0700
> From: "Fajar A. Nugraha" <list at fajar.net>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Freeradius systemd radiusd.service fails
> Message-ID:
>         <CAG1y0scxv33jrdkpdZPmDpJT++XPpww7Je=
> e734Ch1tH8-r-fQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Mar 15, 2016 at 2:27 PM, Ibrahim Almahfooz
> <ibrahim.nezar at 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
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Mar 2016 22:07:16 +1300
> From: Nathan Ward <lists+freeradius at daork.net>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Freeradius systemd radiusd.service fails
> Message-ID: <DE682529-FA45-419F-82D1-4B4A1276E229 at daork.net>
> Content-Type: text/plain; charset=utf-8
>
> > On 15/03/2016, at 21:44, Fajar A. Nugraha <list at fajar.net> wrote:
> >
> > On Tue, Mar 15, 2016 at 2:27 PM, Ibrahim Almahfooz
> > <ibrahim.nezar at 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
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 15 Mar 2016 09:10:05 +0000
> From: Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>, Ibrahim Almahfooz
>         <ibrahim.nezar at gorannet.net>
> Subject: Re: Freeradius systemd radiusd.service fails
> Message-ID: <6C7500E0-39B7-4BE4-BB03-6B8EAE15F2B1 at lboro.ac.uk>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Mar 2016 10:32:00 +0000
> From: Richard J Palmer <richard at merula.net>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Network Design - FreeRadius
> Message-ID: <56e7e4a0.1078.c84.9b5 at merula.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
> Hi
>
> Currently I have a NAS device in a hosting centre and the SQL Server
> with the auth and accounting data in another data centre.
>
> There's a 1G link between the two and the ping time between them is
> ~9ms
>
> In time I am hoping to move the SQL server closer to the main NAS, but
> for now would the best option be to place the FR server closer to the
> NAS (with a higher latency to the SQL server) OR place the FR serve
> closer to the SQL box ?
>
> Currently I have the FR server near the NAS and the SQL server remote
> - but wanted to check this was 'sensible'
>
> Moving to FR 3 (from an old server with 2.12) I am seeing more log
> messages like:
>
> Tue Mar 15 10:26:24 2016 : Error: (27774) Ignoring duplicate packet
> from client mer-fire11 port 3799 - ID: 181 due to unfinished request
> in component post-auth module sql
>
> and
>
>
> Tue Mar 15 10:27:12 2016 : Error: (27785) Discarding duplicate request
> from client mer-fire11 port 3799 - ID: 158 due to delayed response
>
> I have my DBA checking the radius server to see if anything can be
> tuned here - but I wanted to ensure we had the best possible setup
> here - We are using MSSQL as the backend here - via UnixODBC/freetds
>
> Thanks in advance
>
> Richard
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 15 Mar 2016 10:54:03 +0000
> From: Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Network Design - FreeRadius
> Message-ID: <493E2773-63FC-4B6E-87F3-2F2E48A6DBAF at freeradius.org>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On 15 Mar 2016, at 10:32, Richard J Palmer <richard at merula.net> wrote:
> >
> >
> > Hi
> >
> > Currently I have a NAS device in a hosting centre and the SQL Server
> with the auth and accounting data in another data centre.
> >
> > There's a 1G link between the two and the ping time between them is ~9ms
> >
> > In time I am hoping to move the SQL server closer to the main NAS, but
> for now would the best option be to place the FR server closer to the NAS
> (with a higher latency to the SQL server) OR place the FR serve closer to
> the SQL box ?
>
> FR closer to SQL.  Latency between NAS and FR doesn't prevent requests
> being served, whereas latency between FR and SQL does (because of FR's
> blocking architecture).  There's also likely to be more chatter between FR
> and SQL.  RADIUS is a pretty simple protocol, just request/response.
>
> You likely won't see a performance (or latency) difference until you put
> the system under load.
>
> >
> > Currently I have the FR server near the NAS and the SQL server remote -
> but wanted to check this was 'sensible'
> >
> > Moving to FR 3 (from an old server with 2.12) I am seeing more log
> messages like:
> >
> > Tue Mar 15 10:26:24 2016 : Error: (27774) Ignoring duplicate packet from
> client mer-fire11 port 3799 - ID: 181 due to unfinished request in
> component post-auth module sql
>
> Yeah, SQL DB being slow.
>
> -Arran
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS development team
>
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 872 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160315/8561c1ec/attachment-0001.sig
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
> ------------------------------
>
> End of Freeradius-Users Digest, Vol 131, Issue 41
> *************************************************
>



--