As rdate does not actually start any daemons, and it is actually an annoyance having to run '/etc/init.d/rdate zap' before '/etc/init.d/rdate start' can be used again, this patch modifies its init script such that it will never be marked as "started". Although it may not be a pretty solution, it appears to work, and runscript did not complain at all in my tests. The patch also uses the timeout functionality built into rdate as opposed to using kill. This, however, does mean rdate's output is not suppressed. #48493 is related, but old. I am willing to work on a patch for 1.4 to add quiet functionality if the ebuild patch will be considered for acceptance if provided with a quiet-mode patch. Reproducible: Always Steps to Reproduce:
Created attachment 111649 [details, diff] init script patch
(In reply to comment #0) > As rdate does not actually start any daemons, and it is actually an annoyance > having to run '/etc/init.d/rdate zap' before '/etc/init.d/rdate start' can be > used again What's wrong with /etc/init.d/rdate restart? It doesn't work, or... ?
(In reply to comment #2) > What's wrong with /etc/init.d/rdate restart? It doesn't work, or... ? Nope, works perfectly fine. I did it more to satisfy my own curiosity, as, functionally, the current init script works just fine. Figured I'd submit it to see if anyone else agreed this is a more fitting way to show rdate's functionality--hence, "enhancement" :)
I'm inclined to think rdate should stay started, as I'm worried about infinite loops if it clears it's started state, or always returns a fail. In both of these cases, services that use/need/depend on rdate will never start.
(In reply to comment #4) That's a fair concern. However, are there any components that depends on rdate? Or, more generally, is it even appropriate to depend on any component that simply updates the system time? In any case, I think it's still a good idea to move to using rdate's built-in timeout functionality rather than killing it after a certain time. Although definitely very unlikely, the possibility that kill can cause rdate to terminate at an inappropriate state or even accidentally kill the wrong process is non-zero.
our baselayout guys say the it should remain started, and not clear itself up. Another breakage case I thought of is systems that try to keep apps in the runlevel started. These would repeatedly run rdate.
Okay, that's fair. What about the use built-in timeout portion? New bug?
yes please.
