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
