[I wasn't going to reply; but after thinking about it for quite a while, there are a few points here that deserve just a bit of level-headed attention.] On 07/11/2014 10:53 AM, David G. Miller wrote: > Les Mikesell <lesmikesell at ...> writes: > >> Or, if you want things to respawn, the original init handled that >> very nicely via inittab. Replying to Les' comment: the original inittab respawn method is completely brain-dead, blindly respawning without any thought for what conditions might need to be checked, etc. > Just pointing out one of several approaches to respawning a daemon without > the overhead of systemd. Replying to David: So you'd prefer the overhead of cron plus shells plus a bit of arcane syntax? When I first replied to this crontab line, I honestly thought you were being tongue-in-cheek. I have a similar sort of kluge in place, on a CentOS 6 system at a client, that uses the autossh package to hold open ssh reverse tunnels; reverse tunnels are great when the client's machine is behind a known-to-change-frequently dynamic address. > I went with this approach since the problem is not > with radvd or its init script but with my IPv6 tunnel provider. Sounds like something that systemd's concept of process dependencies could solve for you with an easier (and non-executable) syntax. Systemd provides an 'OnFailure' directive that allows you to do whatever you'd like upon failure of an particular 'unit.' That sort of mechanism might allow you to implement the process equivalent of Cisco IOS' IP SLA's. (You could mount /etc (and /var) noexec and have /usr and friends mounted read-only, even.) > I wanted > something that didn't require modifying any of the installed bits. This is why sysadmin configs for systemd are in /etc and the OS-supplied configs are in /usr. Your /etc 'units' to systemd will override the OS installed ones, and are all collected together in one well-defined and standard place. > This > approach also means that updates to radvd and friends don't overwrite my > modifications. This is why sysadmin configs for systemd are in /etc and the OS-supplied configs are in /usr. Your /etc 'units' for systemd will not be touched by the updates to the OS-supplied ones. > Just "playing with" the IPv6 stuff so having it down for up > to five minutes also isn't a problem. The source of the problem goes away > when my ISP provides IPv6 and I don't need to tunnel IPv6 in IPv4 anymore. If you can figure out IPv6 then systemd should be no sweat. > I look at systemd as being yet another nuclear fly swatter. Overkill for > simple problems that can and should be be addressed at the problem without a > sweeping, system level change. I have done all of the various init styles at various times, so I make this statement having 27 years of experience dealing with Unix-like systems (I won't bore anyone with the list): in my quick perusal of systemd and its documentation, I'm cautiously optimistic that maybe finally we have something that a sysadmin can really make sing. Time will tell, of course, whether systemd actually addresses the core problems or not; we've already had one round of an init replacement, Upstart, that didn't succeed in fully addressing the core problems (but will be with us until 2020 as part of EL6). And I always reserve the right to be wrong. But traditional SystemV init last appears in EL5, which, while it is still supported until 2017, is two major versions old at this point. And in case you missed the announcement from Red Hat, EL5.11 is the last minor version update of EL5, with subsequent updates being released as they come and not batched into point releases. (I now know my last targeted version for IA64 rebuilding, which is good.....as long as I can put in some automation to grab updates from then on).