Bug 217055 - Consolidate random sleeps in periodic scripts

[Alan Somers]

On Tue, Feb 14, 2017 at 4:36 AM, Martin S. Weber <Ephaeton at gmx.net> wrote:
> On 2017-02-13 22:47:31, Cy Schubert wrote:
> (...)
>> Hi Alan,
>>
>> Looking at ntp, it backgrounds itself:
>>
>>       (sleep $(jot -r 1 0 3600); service ntpd onefetch) &
>>
>> To facilitate debugging, I can commit the following, if you don't mind.
>>
>> Index: periodic/daily/480.leapfile-ntpd
>> ===================================================================
>> --- periodic/daily/480.leapfile-ntpd  (revision 313710)
>> +++ periodic/daily/480.leapfile-ntpd  (working copy)
>> @@ -13,6 +13,7 @@
>>
>>  case "$daily_ntpd_leapfile_enable" in
>>      [Yy][Ee][Ss])
>> +     tty >/dev/null 2>&1 && daily_ntpd_avoid_congestion=NO
>>       case "$daily_ntpd_avoid_congestion" in
>>       [Yy][Ee][Ss])
>>           # Avoid dogpiling
>
> You are aware that these files are invoked with < /dev/null and > file 2>&1 ?
>
> Problem with sleeping from periodic from the command line is that these
> extra I/O indirections make it impossible from the script file itself
> to determine whether or not the parent process is running from a tty
> or not.
>
> Cf. /usr/sbin/periodic:118
>
> For the purpose of "my" PR, your fix is useless. An environment variable
> could be set that stored the fact whether or not invoker is on a TTY,
> and this again be checked from within the periodic scripts themselves
> to determine whether or not we should sleep.
>
> Btw, I hate systemd & dbus, but the discussion so far really looks like
> the vanilla argument "pro" SOA-style module startup :(
>
> Regards,
>
> -Martin

Ok, the consensus opinion seems to be that:
1) A single sleep would be better than 3 sleeps
2) Periodic shouldn't sleep if no script requires it
3) Nothing should be backgrounded
4) Periodic shouldn't sleep when run interactively.

I can achieve all of this by putting a common sleep function in
/etc/defaults/periodic.conf.  Some passing of environment variables
will be required.  I'll put everyone on the code review when it's
ready.

-Alan