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