Hi, (switching to devel) (for the benefit of those who don't have the FC16 file at hand, original is attached) ah, that looks like a good start already. Some things of interest maybe: ExecStartPre=/usr/sbin/radiusd -C ExecStart=/usr/sbin/radiusd -d /etc/raddb The config check doesn't explicitly set the config dir, while startup does. if $raddbdir != /etc/raddb, the config check will test a different configuration than what startup uses. On FC, you may simply want to set that in sync (with FR's built-in knowledge where to find raddb, maybe simply leave out the -d on ExecStart?), but for the general distribution, we could include it into the "auto" build system so that all paths are filled in with what is set during configure time. Would affect PIDFile=/var/run/radiusd/radiusd ExecStartPre=-/bin/chown -R radiusd.radiusd /var/run/radiusd ExecStartPre=/usr/sbin/radiusd -C ExecStart=/usr/sbin/radiusd -d /etc/raddb ExecReload=/usr/sbin/radiusd -C All these work on explicit paths. I'm not much into autohell, what I meant is that there should be some kind of "radiusd.service.in" which expands PIDFile=${localstatedir}/run/radiusd/radiusd ExecStartPre=-/bin/chown -R radiusd.radiusd ${localstatedir}/run/radiusd ExecStartPre=/usr/sbin/radiusd -C ExecStart=${sbindir}/radiusd ExecReload=${sbindir}/radiusd -C during "make" to the values that were found out/set during configure. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 10/28/2011 08:12 AM, Stefan Winter wrote:
Hi,
(switching to devel)
(for the benefit of those who don't have the FC16 file at hand, original is attached)
ah, that looks like a good start already. Some things of interest maybe:
Couple of throw-away thoughts on systemd: 1. Does systemd have any native support for "multi-instance" stuff i.e. init scripts that start N processes, for N config files in a central location? We use a local, custom init script to run several radius processes to isolate potential (thankfully rare!) failures (e.g. our wireless/802.1x server going down is bad, but our wired/macauth server going down is a four-alarm disaster, so we keep them in separate processes) 2. Aren't processes meant to be started in foreground and log to stdout/stderr? 3. It's not clear to me that any of the socket activation stuff makes sense for a radius server?
Phil Mayers wrote:
3. It's not clear to me that any of the socket activation stuff makes sense for a radius server?
I don't know if it makes sense. The main reason is to delay loading it until the first RADIUS packet comes in. This might help with CPU / disk contention at bootup time. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
The main reason is to delay loading it until the first RADIUS packet comes in. This might help with CPU / disk contention at bootup time.
This might just be me, but one issue I have never worried about is the boot time for our radius servers. I assume that most of it will be lost in fsck anyway, since it will probably be a few years since the last time the file systems were mounted. Or let me put it another way: What possible features of systemd would make it worth the job of changing customized startup scripts on a server class system? I see systemd as a destop tool, which will probably progress the same way as (all?) other desktop system tools have: 1) a lot of noise and "everone have to adapt to us" 2) bugs 3) more bugs 4) a "new and better way" is found, and all developers move on 5) goto 1 Remember hal anyone? I think I'm going to wait a couple of years to see how this goes before even considering systemd on any radius server. Bjørn
Hi,
Couple of throw-away thoughts on systemd:
1. Does systemd have any native support for "multi-instance" stuff i.e. init scripts that start N processes, for N config files in a central location? We use a local, custom init script to run several radius processes to isolate potential (thankfully rare!) failures (e.g. our wireless/802.1x server going down is bad, but our wired/macauth server going down is a four-alarm disaster, so we keep them in separate processes)
2. Aren't processes meant to be started in foreground and log to stdout/stderr?
It supports many ways of operation. The usual forking is supported just fine. If it knows the PID, it will constantly check if the service is still up and can be configured to restart if the PID disappears. That's something I was considering to put in my version, but I need to think through if that's really what I want. Probably yes, if I will also get an out-of-band notify that a restart happened. I don't want it to go in cycles every few hours without our monitoring noticing. Yes, I know, you could already do this earlier on with inittab and respawn. This new way looks much more flexible though, and it's all configured in single service configuration file. Not as a symlink in a rc.d directory + extra stuff in inittab.
3. It's not clear to me that any of the socket activation stuff makes sense for a radius server?
That part is not a winner for me either (not caring the slightest about startup time). Or even D-Bus integration. Dreadful to even think about, for a server daemon. Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 28/10/11 13:34, Stefan Winter wrote:
2. Aren't processes meant to be started in foreground and log to stdout/stderr?
It supports many ways of operation. The usual forking is supported just fine. If it knows the PID, it will constantly check if the service is still up and can be configured to restart if the PID disappears.
Keeping in the foreground is, of course, easy - it's an existing command-line switch. If systemd can do decent restart / "notify if constantly rebooting" then it's a bonus.
participants (4)
-
Alan DeKok -
Bjørn Mork -
Phil Mayers -
Stefan Winter