[Bug 2043140] [NEW] cron @reboot jobs race with setup of files under /sys

[Britton Kerin]

Public bug reported:


It looks like @reboot cron jobs run before /sys is fully populated.  This is super-unexpected and very bad,
since the desire and expectation for things in this slot is pretty much always going to be to do something
"last" in the boot process.  The user will have something they've discovered they have to do and now they
want to make it automatic *exactly as if they did it manually every boot*.

The evidence of the problem:

I have the caps-lock-decreases-brightness bug and rather than deal with
kernel compilation I thought I'd just fix it using a cron job and
/sys/class/backlight/intel_backlight/brightness to force it high all the
time.  The script I wrote worked fine from command line but not when run
as a root cron job at @reboot like this:

     SHELL=/bin/bash
     PATH=/usr/sbin:/usr/bin:/sbin:/bin
     @reboot /home/bkerin/.helper_scripts/brighterizer.perl

When run from cron, my script would die the first time it tried to read the
/sys/class/backlight/intel_backlight/max_brightness file.  The fix turned out
to be to just wait in the script until the file shows up:

     # Max Brightness File
     my $mbf = '/sys/class/backlight/intel_backlight/max_brightness';
     # Current Brightness File
     my $cbf = '/sys/class/backlight/intel_backlight/brightness';
 
     # Because it looks like the contents of /sys aren't all entirely populated
     # before @reboot cron jobs run, since without these (or one or the other
     # of themn anyway) the first cat below fails when we're invoked from reboot
     # (but not otherwise).
     while ( not -r $mbf ) { sleep 0.1; }
     while ( not -r $cbf ) { sleep 0.1; }

     # Max Brightness
     my $mb = `cat $mbf`;
     $? == 0 or die;
     chomp($mb);


>From this behavior I conclude that the @reboot cron job races with setup of files under /sys.  For the reasons mentioned above this should be fixed.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: cron 3.0pl1-137ubuntu3
ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16
Uname: Linux 6.2.0-36-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov  9 11:11:14 2023
InstallationDate: Installed on 2023-11-04 (5 days ago)
InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cron
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: cron (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug jammy wayland-session

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cron in Ubuntu.
https://bugs.launchpad.net/bugs/2043140

Title:
  cron @reboot jobs race with setup of files under /sys

Status in cron package in Ubuntu:
  New

Bug description:
  
  It looks like @reboot cron jobs run before /sys is fully populated.  This is super-unexpected and very bad,
  since the desire and expectation for things in this slot is pretty much always going to be to do something
  "last" in the boot process.  The user will have something they've discovered they have to do and now they
  want to make it automatic *exactly as if they did it manually every boot*.

  The evidence of the problem:

  I have the caps-lock-decreases-brightness bug and rather than deal
  with kernel compilation I thought I'd just fix it using a cron job and
  /sys/class/backlight/intel_backlight/brightness to force it high all
  the time.  The script I wrote worked fine from command line but not
  when run as a root cron job at @reboot like this:

       SHELL=/bin/bash
       PATH=/usr/sbin:/usr/bin:/sbin:/bin
       @reboot /home/bkerin/.helper_scripts/brighterizer.perl

  When run from cron, my script would die the first time it tried to read the
  /sys/class/backlight/intel_backlight/max_brightness file.  The fix turned out
  to be to just wait in the script until the file shows up:

       # Max Brightness File
       my $mbf = '/sys/class/backlight/intel_backlight/max_brightness';
       # Current Brightness File
       my $cbf = '/sys/class/backlight/intel_backlight/brightness';
   
       # Because it looks like the contents of /sys aren't all entirely populated
       # before @reboot cron jobs run, since without these (or one or the other
       # of themn anyway) the first cat below fails when we're invoked from reboot
       # (but not otherwise).
       while ( not -r $mbf ) { sleep 0.1; }
       while ( not -r $cbf ) { sleep 0.1; }

       # Max Brightness
       my $mb = `cat $mbf`;
       $? == 0 or die;
       chomp($mb);

  
  From this behavior I conclude that the @reboot cron job races with setup of files under /sys.  For the reasons mentioned above this should be fixed.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: cron 3.0pl1-137ubuntu3
  ProcVersionSignature: Ubuntu 6.2.0-36.37~22.04.1-generic 6.2.16
  Uname: Linux 6.2.0-36-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Nov  9 11:11:14 2023
  InstallationDate: Installed on 2023-11-04 (5 days ago)
  InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/2043140/+subscriptions