Control socket directory doesn't exist after systemd stopping service

Wed Nov 30 03:29:25 UTC 2022

Correcting the previous command I sent:

mkdir -p /var/run/radiusd && chown radiusd:radiusd /var/run/radiusd && chmod 750 /var/run/radiusd && radiusd -X

Warm Regards,

.[cid:vg-email_e752d47f-182a-48d0-8808-3796b2df8d4a.png]<https://www.vetta.nz>  .[cid:058_line_9bae9502-1e3a-48a3-ba5e-34ed9cd44185.png]        Matthew McTague
Head of Infrastructure  [cid:bea-finalist-email_2ddba0ed-b9bb-4ab9-b680-84aa7f54077f.png]  [cid:bea-winner-banner-email_590096c3-05a6-4c98-b071-1c4d748c3534.png] .
D +64 3 222 6013<tel:+64%203%20222%206013> | P +64 3 684 5770
E matthew.mctague at vetta.nz<mailto:matthew.mctague at vetta.nz> | W www.vetta.nz<https://www.vetta.nz>
🎄 Christmas/New Year Holiday Period 🎄
During the period from 22rd December to 9th January, our offices will be closed, with our teams available via our after-hours service methods, focused on service continuity and restoration only. For more details, click here<https://vetta.link/xmas22email> .
Vetta Group Ltd and its subsidiaries accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company, its subsidiaries, partners or contractors.
.
From: Matthew McTague <matthew.mctague at vetta.nz>
Sent: Wednesday, 30 November 2022 4:27 pm
To: Alan DeKok <aland at deployingradius.com>; FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: RE: Control socket directory doesn't exist after systemd stopping service

Hi Alan,

If I create the directory before running debug, with the below, yes it works.

mkdir -p /var/run/radiusd && chown radiusd:radiusd /var/run/radiusd && chmod 750 /var/run/radiusd  radiusd -X

Is there any better / transparent way to do this, or to stop systemd from removing the directory when stopping the service?
Or would it be better to use /var/run/radiusd.sock for the socket and avoid the usage of a subdirectory?

Warm Regards,
.[cid:image001.png at 01D904D8.E91AB930]<https://www.vetta.nz/>

.[cid:image002.png at 01D904D8.E91AB930]

Matthew McTague
Head of Infrastructure

[cid:image003.png at 01D904D8.E91AB930][cid:image004.png at 01D904D8.E91AB930].

D +64 3 222 6013<tel:+64%203%20222%206013> | P +64 3 684 5770
E matthew.mctague at vetta.nz<mailto:matthew.mctague at vetta.nz> | W www.vetta.nz<https://www.vetta.nz>

🎄 Christmas/New Year Holiday Period 🎄
During the period from 22rd December to 9th January, our offices will be closed, with our teams available via our after-hours service methods, focused on service continuity and restoration only. For more details, click here<https://vetta.link/xmas22email> .

Vetta Group Ltd and its subsidiaries accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company, its subsidiaries, partners or contractors.
.

-----Original Message-----
From: Alan DeKok <aland at deployingradius.com<mailto:aland at deployingradius.com>>
Sent: Wednesday, 30 November 2022 10:41 am
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org<mailto:freeradius-users at lists.freeradius.org>>
Cc: Matthew McTague <matthew.mctague at vetta.nz<mailto:matthew.mctague at vetta.nz>>
Subject: Re: Control socket directory doesn't exist after systemd stopping service

On Nov 29, 2022, at 3:52 PM, Matthew McTague via Freeradius-Users <freeradius-users at lists.freeradius.org<mailto:freeradius-users at lists.freeradius.org>> wrote:
> I have a weird bug where the control socket directory `/var/run/radiusd` gets deleted after `systemctl stop radiusd`, and `radiusd -X` doesn't re-create it.

  Depending on the OS and configuration, the server doesn't create that directory.  In this case, it's relying on systemd to create it.

> I'm using the Rocky repo as there's no AlmaLinux repo available, although I'm expecting this would be compatible.
>
> Extra information is below in case it's needed for context.
>
> Excerpt from radiusd -X output:
>
> radiusd: #### Opening IP addresses and Ports #### listen {
>        type = "control"
> listen {
>        socket = "/var/run/radiusd/radiusd.sock"
>        mode = "rw"
>        peercred = yes
> }
> Failed creating control socket "/var/run/radiusd/radiusd.sock": Failed
> binding to /var/run/radiusd/radiusd.sock: No such file or directory

  Was this run as root?  Or as a non-root user?

> The directory doesn't exist:
>
> # ls -lah /var/run/radiusd
> ls: cannot access '/var/run/radiusd': No such file or directory

  How about:

$ mkdir /var/runradiusd && radiusd -X

  ?

> I tried radiusd -X with strace attached, showed the same thing, excerpt below:
> ...
> socket(AF_UNIX, SOCK_STREAM, 0)         = 22
> stat("/var/run/radiusd/radiusd.sock", 0x7fff5e30c580) = -1 ENOENT (No
> such file or directory) bind(22, {sa_family=AF_UNIX,
> sun_path="/var/run/radiusd/radiusd.sock"}, 31) = -1 ENOENT (No such
> file or directory)

  Yup.  It's requiring that the directory exist.

  Because generally the server shouldn't have write permission to /var/run.  That directory is owned by "root", and it's very bad to have a non-root program write to it.

  The directory /var/run/radiusd should be owned by "radiusd", and the server should have write permission to that directory.

  So... make sure that the directory exists before starting the server in debug mode.

  Alan DeKok.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9436 bytes
Desc: image001.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1556 bytes
Desc: image002.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 43246 bytes
Desc: image003.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 44719 bytes
Desc: image004.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vg-email_e752d47f-182a-48d0-8808-3796b2df8d4a.png
Type: image/png
Size: 9436 bytes
Desc: vg-email_e752d47f-182a-48d0-8808-3796b2df8d4a.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 058_line_9bae9502-1e3a-48a3-ba5e-34ed9cd44185.png
Type: image/png
Size: 1556 bytes
Desc: 058_line_9bae9502-1e3a-48a3-ba5e-34ed9cd44185.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bea-finalist-email_2ddba0ed-b9bb-4ab9-b680-84aa7f54077f.png
Type: image/png
Size: 43246 bytes
Desc: bea-finalist-email_2ddba0ed-b9bb-4ab9-b680-84aa7f54077f.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bea-winner-banner-email_590096c3-05a6-4c98-b071-1c4d748c3534.png
Type: image/png
Size: 44719 bytes
Desc: bea-winner-banner-email_590096c3-05a6-4c98-b071-1c4d748c3534.png
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20221130/c9cc1a0f/attachment-0015.png>