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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp