where are the crontab files in Trixie?

[Gary Dale]

I'm running Debian/Trixie on an AMD64 system. I have an old wifi adapter
that Linux has problems with that works once I run:

/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

However when I add those lines to the root's crontab using # crontab -e as

@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

the second line fails. I get an e-mail stating "/bin/sh: 1: cannot
create /sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

I'm not sure if the modprobe is working or if the module is being loaded
without it. It's likely that debian detects the need for the module and
loads it.

Anyway, that got me down the rabbit hole to try to find where the
crontab file is.

 ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory

also

# whereis crontab
crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz
/usr/share/man/man5/crontab.5.gz

so it's not in the location that you'd expect. Nor can I find it in
/etc/. The various cron files there don't contain the lines I;m looking for.

However, running crontab -e as root definitely shows the file I expect
to see.  Specifically:

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

Looking at systemd-timers doesn't show anything obvious either.

Can anyone explain how Trixie is handling crontabs now?

[Kushal Kumaran]

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system. I have an old wifi
/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
However when I add those lines to the root's crontab using # crontab -e as
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
the second line fails. I get an e-mail stating "/bin/sh: 1: cannot
create /sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"
I'm not sure if the modprobe is working or if the module is being
loaded without it. It's likely that debian detects the need for the
module and loads it.

Is it possible that the command is being run before the module is
loaded. Consider putting both into a single command, perhaps by writing
a script that does both things.

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the
crontab file is.
 ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory
also
# whereis crontab
crontab: /usr/bin/crontab /etc/crontab
/usr/share/man/man1/crontab.1.gz /usr/share/man/man5/crontab.5.gz
so it's not in the location that you'd expect. Nor can I find it in
/etc/. The various cron files there don't contain the lines I;m looking for.

Editing/creating crontab files using "crontab -e" creates it in
/var/spool/cron/crontabs.

Post by Gary Dale
<snipped crontab content>
Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever. I'm on bookworm, though, so no idea
if anything is changing in trixie.

[Gary Dale]

Post by Kushal Kumaran

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system. I have an old wifi
/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
However when I add those lines to the root's crontab using # crontab -e as
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
the second line fails. I get an e-mail stating "/bin/sh: 1: cannot
create /sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"
I'm not sure if the modprobe is working or if the module is being
loaded without it. It's likely that debian detects the need for the
module and loads it.

Is it possible that the command is being run before the module is
loaded. Consider putting both into a single command, perhaps by writing
a script that does both things.

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the
crontab file is.
 ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory
also
# whereis crontab
crontab: /usr/bin/crontab /etc/crontab
/usr/share/man/man1/crontab.1.gz /usr/share/man/man5/crontab.5.gz
so it's not in the location that you'd expect. Nor can I find it in
/etc/. The various cron files there don't contain the lines I;m looking for.

Editing/creating crontab files using "crontab -e" creates it in
/var/spool/cron/crontabs.

Post by Gary Dale
<snipped crontab content>
Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever. I'm on bookworm, though, so no idea
if anything is changing in trixie.

The debian wiki suggests that the handling of cron/anacron is evolving.

[Jeffrey Walton]

Post by Gary Dale

Post by Kushal Kumaran

Post by Gary Dale
[...]
Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever. I'm on bookworm, though, so no idea
if anything is changing in trixie.

The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.

Jeff

[Gary Dale]

Post by Jeffrey Walton

Post by Gary Dale

Post by Kushal Kumaran

Post by Gary Dale
[...]
Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever. I'm on bookworm, though, so no idea
if anything is changing in trixie.

The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.
Jeff

There are a lot of things going on these days that don't seem quite
ready for prime time.

Examples include systemd networking, which remains woefully ill-equipped
to deal with bonding and wifi.

Wayland may have some good things to say about it but when I try it, it
messes up my desktop. I have my desktop scaled to 150% to help with my
old eyes, but Wayland doesn't seem to apply it to text, which is where I
really need it.

I'm hoping Plasma 6 will address the Wayland issues at least.

[Gremlin]

Post by Gary Dale

Post by Jeffrey Walton

Post by Gary Dale

On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale

Post by Gary Dale
[...]
Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever.  I'm on bookworm, though, so no idea
if anything is changing in trixie.

The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.
Jeff

There are a lot of things going on these days that don't seem quite
ready for prime time.
Examples include systemd networking, which remains woefully ill-equipped
to deal with bonding and wifi

LOL

https://wiki.archlinux.org/title/Systemd-networkd
https://wiki.archlinux.org/title/Wireless_bonding

I am using systemd-networkd and systemd-resolved and have removed
Networkmanager, ifupdown and isc-dhcp. Also avahi, modemmanager,
openssh-sftp-server openssh-server and openssh-sk-helper

They ain't needed

Post by Gary Dale
Wayland may have some good things to say about it but when I try it, it
messes up my desktop. I have my desktop scaled to 150% to help with my
old eyes, but Wayland doesn't seem to apply it to text, which is where I
really need it.
I'm hoping Plasma 6 will address the Wayland issues at least.

Using wayland with lxde

ii libqt5waylandclient5:arm64 5.15.8-2
arm64 QtWayland client library
ii libqt5waylandcompositor5:arm64 5.15.8-2
arm64 QtWayland compositor library
ii libva-wayland2:arm64 2.17.0-1
arm64 Video Acceleration (VA) API for Linux -- Wayland runtime
ii libwayland-client0:arm64 1.21.0-1
arm64 wayland compositor infrastructure - client library
ii libwayland-cursor0:arm64 1.21.0-1
arm64 wayland compositor infrastructure - cursor library
ii libwayland-egl1:arm64 1.21.0-1
arm64 wayland compositor infrastructure - EGL library
ii libwayland-server0:arm64 1.21.0-1
arm64 wayland compositor infrastructure - server library
ii libwlroots11:arm64 0.16.0-2~bpo11+1~rpt13
arm64 Modular wayland compositor library - shared library
ii qtwayland5:arm64 5.15.8-2
arm64 QtWayland platform plugin
ii xwayland 2:22.1.9-1
arm64 X server for running X clients under Wayland
ii wayfire 0.7.5-1~bpo11+1~rpt33
arm64 3D Wayland compositor
ii wayvnc 0.8.0-rc0-2
arm64 VNC server for wlroots-based Wayland compositors
ii xwayland 2:22.1.9-1
arm64 X server for running X clients under Wayland

ii lxde-common 0.99.2-4
all LXDE common configuration files
ii lxde-core 11+rpt1
all metapackage for the LXDE core
ii lxde-icon-theme 0.5.1-2.1
all LXDE standard icon theme
ii openbox-lxde-session 0.99.2-4
all LXDE session manager and configuration files

[Charles Curley]

On Tue, 27 Feb 2024 14:13:49 -0500

Post by Jeffrey Walton

Post by Gary Dale
The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.

These days cron and anacron are run as services/timers by systemd.

***@hawk:~# systemctl list-units '*cron*'
UNIT LOAD ACTIVE SUB DESCRIPTION
cron.service loaded active running Regular background program processing daemon
anacron.timer loaded active waiting Trigger anacron every hour
nextcloudcron.timer loaded active waiting Run Nextcloud cron.php every 5 minutes

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
***@hawk:~#

[Greg Wooledge]

Post by Charles Curley
On Tue, 27 Feb 2024 14:13:49 -0500

Post by Jeffrey Walton

Post by Gary Dale
The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.

These days cron and anacron are run as services/timers by systemd.
UNIT LOAD ACTIVE SUB DESCRIPTION
cron.service loaded active running Regular background program processing daemon
anacron.timer loaded active waiting Trigger anacron every hour
nextcloudcron.timer loaded active waiting Run Nextcloud cron.php every 5 minutes

Systemd timers are designed to replace crontabs, but that's not what
cron.service is. cron.service runs an actual cron daemon.

hobbit:~$ systemctl status cron
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-02-17 20:45:06 EST; 1 week 2 days >
Docs: man:cron(8)
Main PID: 789 (cron)
Tasks: 1 (limit: 18738)
Memory: 21.9M
CPU: 5.275s
CGroup: /system.slice/cron.service
└─789 /usr/sbin/cron -f

hobbit:~$ ps -fp 789
UID PID PPID C STIME TTY TIME CMD
root 789 1 0 Feb17 ? 00:00:01 /usr/sbin/cron -f

I don't foresee real cron going away any time soon. If systemd wants to
create an alternative to it, that's fine, but people know cron, they
like cron, and they *trust* cron. Systemd timers don't have any of those
benefits yet.

[Gremlin]

Post by Greg Wooledge

Post by Charles Curley
On Tue, 27 Feb 2024 14:13:49 -0500

Post by Jeffrey Walton

Post by Gary Dale
The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.

These days cron and anacron are run as services/timers by systemd.
UNIT LOAD ACTIVE SUB DESCRIPTION
cron.service loaded active running Regular background program processing daemon
anacron.timer loaded active waiting Trigger anacron every hour
nextcloudcron.timer loaded active waiting Run Nextcloud cron.php every 5 minutes

Systemd timers are designed to replace crontabs, but that's not what
cron.service is. cron.service runs an actual cron daemon.
hobbit:~$ systemctl status cron
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-02-17 20:45:06 EST; 1 week 2 days >
Docs: man:cron(8)
Main PID: 789 (cron)
Tasks: 1 (limit: 18738)
Memory: 21.9M
CPU: 5.275s
CGroup: /system.slice/cron.service
└─789 /usr/sbin/cron -f
hobbit:~$ ps -fp 789
UID PID PPID C STIME TTY TIME CMD
root 789 1 0 Feb17 ? 00:00:01 /usr/sbin/cron -f
I don't foresee real cron going away any time soon. If systemd wants to
create an alternative to it, that's fine, but people know cron, they
like cron, and they *trust* cron. Systemd timers don't have any of those
benefits yet.

I purged cron from my systems and I use systemd-timers

[Andy Smith]

Hello,

Post by Greg Wooledge
I don't foresee real cron going away any time soon.

If you today install bookworm base system and select no packages,
the only reason why you get cron is because logrotate depends upon
it. If you do not need logrotate then you can also remove cron, and
nothing complains.

It seems likely that at some point logrotate will become optional
(because of journald) or that logrotate will get a systemd timer, at
which point cron wouldn't be installed on a base install unless
there is some other package dependency.

On this list we already saw a post from someone who did not have
cron installed. Initially I thought that was a rather bold
modification by their hosting provider, but it turned out that they
really did have no package that depended upon cron.

So as far as Debian is concerned I do see it as fairly inevitable
that cron soon doesn't get installed on many systems and
increasingly becomes a curiosity, but since it will have to stick
around until the last package stops shipping (only) a cron job,
arguably it still remains in the archive for a very long time yet.

Thanks,
Andy

[The Wanderer]

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the
crontab file is.
ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory
also
# whereis crontab
crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz
/usr/share/man/man5/crontab.5.gz
so it's not in the location that you'd expect.

I'm not sure whereis is suitable for finding things like this. As its
man page states, it's for finding "the binary, source, and manual page
files for a command" - not the data files which the command may work with.

Post by Gary Dale
Nor can I find it in /etc/. The various cron files there don't
contain the lines I;m looking for.
Can anyone explain how Trixie is handling crontabs now?

Each user can have their own crontab, and though these are files in
/var/spool/cron/crontabs,they are not intended to be edited
directly.

So, while I don't use per-user crontabs myself and so don't have
experience with this personally, I would suggest looking in that
directory - but not necessarily editing the files there, except via
'crontab -e' as you have already done.

[Gary Dale]

Post by The Wanderer

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the
crontab file is.
ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory
also
# whereis crontab
crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz
/usr/share/man/man5/crontab.5.gz
so it's not in the location that you'd expect.

I'm not sure whereis is suitable for finding things like this. As its
man page states, it's for finding "the binary, source, and manual page
files for a command" - not the data files which the command may work with.

locate crontab also fails to find it, as does  find / -name crontab

Post by The Wanderer

Post by Gary Dale
Nor can I find it in /etc/. The various cron files there don't
contain the lines I;m looking for.
Can anyone explain how Trixie is handling crontabs now?

Each user can have their own crontab, and though these are files in
/var/spool/cron/crontabs,they are not intended to be edited
directly.

So, while I don't use per-user crontabs myself and so don't have
experience with this personally, I would suggest looking in that
directory - but not necessarily editing the files there, except via
'crontab -e' as you have already done.

Thanks. I missed that when I was reading the comments.  I need to
enlarge the text more, I guess.

[Greg Wooledge]

as does find / -name crontab

Invoked how? In particular, as which user?
Assuming that the crontab files are actually named literally 'crontab'
with no extra characters (perhaps by being stored one per directory), my
guess would be that this is because /var/spool/cron/crontabs is not
world-executable, and therefore most users won't be able to list its
contents. If you run that 'find' command as root, or as a user which is
in the group that owns the directory, you may see that the files show
up.
(If they aren't literally named just 'crontab' verbatim, then you'd also
need to specify wildcards etc. in the find arguments, in order for it to
recognize them as being a valid match.)

The only file named "crontab" is /etc/crontab.

Per-user crontabs which live in /var/spool/cron/crontabs are named for
their owner.

hobbit:~$ sudo ls /var/spool/cron/crontabs
greg

If you really want to find where the files live, and you didn't happen
to already know (approximately) where they are, and if you haven't been
reading this mailing list thread, then you could try reading cron(8):

NOTES
cron searches its spool area (/var/spool/cron/crontabs) for crontab
files (which are named after accounts in /etc/passwd); crontabs found
are loaded into memory. Note that crontabs in this directory should
not be accessed directly - the crontab command should be used to access
and update them.

This isn't hard to find. Seriously. Even if you tried crontab(1) first,
it's in there too:

DESCRIPTION
crontab is the program used to install, deinstall or list the tables
used to drive the cron(8) daemon in Vixie Cron. Each user can have
their own crontab, and though these are files in
/var/spool/cron/crontabs, they are not intended to be edited directly.

The only place it *isn't* is crontab(5), but hey, two out of three ain't
bad, as someone once sang.

[The Wanderer]

Post by Gary Dale

Post by The Wanderer

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the
crontab file is.
ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory
also
# whereis crontab
crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz
/usr/share/man/man5/crontab.5.gz
so it's not in the location that you'd expect.

I'm not sure whereis is suitable for finding things like this. As
its man page states, it's for finding "the binary, source, and
manual page files for a command" - not the data files which the
command may work with.

locate crontab also fails to find it,

That would be because updatedb is configured to exclude /var/spool and
everything underneath it. Look at /etc/updatedb.conf; you'll probably
find that PRUNEPATHS is set to include /var/spool. (It is on my system,
and I'm reasonably certain that it's by default.)

Post by Gary Dale
as does find / -name crontab

Invoked how? In particular, as which user?

Assuming that the crontab files are actually named literally 'crontab'
with no extra characters (perhaps by being stored one per directory), my
guess would be that this is because /var/spool/cron/crontabs is not
world-executable, and therefore most users won't be able to list its
contents. If you run that 'find' command as root, or as a user which is
in the group that owns the directory, you may see that the files show
up.

(If they aren't literally named just 'crontab' verbatim, then you'd also
need to specify wildcards etc. in the find arguments, in order for it to
recognize them as being a valid match.)

Post by Gary Dale

Post by The Wanderer

Post by Gary Dale
Nor can I find it in /etc/. The various cron files there don't
contain the lines I;m looking for.
Can anyone explain how Trixie is handling crontabs now?

Each user can have their own crontab, and though these are
files in /var/spool/cron/crontabs,they are not intended to be
edited directly.

So, while I don't use per-user crontabs myself and so don't have
experience with this personally, I would suggest looking in that
directory - but not necessarily editing the files there, except
via 'crontab -e' as you have already done.

Thanks. I missed that when I was reading the comments. I need to
enlarge the text more, I guess.

It took a bit of careful looking for me, too, even when I was fairly
sure something like this would be in there.

[Greg Wooledge]

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system. I have an old wifi adapter
/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
However when I add those lines to the root's crontab using # crontab -e as
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
the second line fails. I get an e-mail stating "/bin/sh: 1: cannot create
/sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

Having two separate @reboot lines might run them both in parallel,
rather than sequentially. It might be better to combine them into
one shell command, or one script.

Something like this, perhaps:

@reboot /usr/sbin/modprobe brcmfmac && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

Or put the commands into a shell script, then run the script from crontab.

[Gary Dale]

Post by Greg Wooledge

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system. I have an old wifi adapter
/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
However when I add those lines to the root's crontab using # crontab -e as
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
the second line fails. I get an e-mail stating "/bin/sh: 1: cannot create
/sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

rather than sequentially. It might be better to combine them into
one shell command, or one script.
@reboot /usr/sbin/modprobe brcmfmac && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
Or put the commands into a shell script, then run the script from crontab.

Yep. That works.  Thanks.

[Michael Kjörling]

Post by Gary Dale
However when I add those lines to the root's crontab using # crontab -e as
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
the second line fails. I get an e-mail stating "/bin/sh: 1: cannot create
/sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

Probably a timing issue. "@reboot" crontab entries execute fairly
early (I think it really means "when the cron daemon starts"), and
among crontab entries with the same execution time, I do believe that
execution order is unspecified and execution quite possibly is
parallelized.

Since redirection is done by the shell, and command invocation is also
done by the shell, if the two start executing at the same moment and
execute perfectly in parallel, it seems very likely that the shell
would conclude that the path into which you want to redirect stdout is
nonexistent before modprobe has even finished loading, let alone
finished loading the module.

If two commands must be executed in sequence, either set up the
crontab entries so that the execution times cannot conflict, or
separate the commands with semicolons:

@reboot /usr/sbin/modprobe brcmfmac; echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

In this case you might even want the second to execute only when the
first completes _successfully_, so:

@reboot /usr/sbin/modprobe brcmfmac && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

_That said_, if you want to load a module on boot, the generally
recommended way these days is to add it to a *.conf file in
/etc/modules-load.d. See modules-load.d(5) for details. The old way
was to add it to the file /etc/modules.

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the crontab
file is.

Per-user crontabs are in /var/spool/cron/crontabs, or at least are in
Bookworm (and this has been the case for what feels like forever).
This is mentioned in the DIAGNOSTICS section of the crontab(1) man
page, as well as in the NOTES section of the cron(8) man page.

[David Wright]

Post by Michael Kjörling
In this case you might even want the second to execute only when the
@reboot /usr/sbin/modprobe brcmfmac && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

I wondered whether that might cause any error message to be lost in
normal booting output (assuming you've asked for it).

Post by Michael Kjörling
_That said_, if you want to load a module on boot, the generally
recommended way these days is to add it to a *.conf file in
/etc/modules-load.d. See modules-load.d(5) for details. The old way
was to add it to the file /etc/modules.

In which case, I'd write the remaining cron line as:

@reboot sleep 99 && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

where you can choose a better estimate than 99.

Post by Michael Kjörling

Post by Gary Dale
Anyway, that got me down the rabbit hole to try to find where the crontab
file is.

Per-user crontabs are in /var/spool/cron/crontabs, or at least are in
Bookworm (and this has been the case for what feels like forever).
This is mentioned in the DIAGNOSTICS section of the crontab(1) man
page, as well as in the NOTES section of the cron(8) man page.

If you lose track of where a crontab was originally generated from¹,
the filename is in the second line of /var/spool/cron/crontabs/<username>.

Note that you won't see the first three lines of crontabs/<username>
listed by crontab -l or at the top of the file edited by crontab -e
because they're stripped out and reinserted by crontab². See the
DEBIAN SPECIFIC section in man 1 crontab.

¹ Assuming you use crontab filename. Otherwise, the filename
in crontabs/<username> will be of little interest.

² This behaviour can be overridden with CRONTAB_NOHEADER='N'

Cheers,
David.

[Max Nikulin]

Post by David Wright
@reboot sleep 99 && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

I am in doubts if it is a task for cron. Wouldn't udev rules be better?

https://stackoverflow.com/questions/442833/how-to-force-driver-to-device-match-in-linux/52943745#52943745
https://unix.stackexchange.com/questions/67936/attaching-usb-serial-device-with-custom-pid-to-ttyusb0-on-embedded/165845#165845

Moreover, to load and configure modules there are /etc/modprobe.d/ and
/etc/modules.

If it is a weird device that may appear either as 13b1:0039 (supported
by brcmfmac accordingly to modinfo) and 13b1:0bdc, may it happen that it
is possible to use e.g. usb-modeswitch to adjust which way the device
tries to present itself?

[Nicolas George]

Post by Max Nikulin
I am in doubts if it is a task for cron. Wouldn't udev rules be better?

Or even the good old simple way that still works:

install modulename command...
This command instructs modprobe to run your command instead of
inserting the module in the kernel as normal. The command can be
any shell command: this allows you to do any kind of complex
processing you might wish. For example, if the module "fred" works
better with the module "barney" already installed (but it doesn't
depend on it, so modprobe won't automatically load it), you could
say "install fred /sbin/modprobe barney; /sbin/modprobe
--ignore-install fred", which would do what you wanted. Note the
--ignore-install, which stops the second modprobe from running the
same install command again. See also remove below.

Regards,

[David Wright]

Post by Max Nikulin

Post by David Wright
@reboot sleep 99 && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

I am in doubts if it is a task for cron. Wouldn't udev rules be better?
https://stackoverflow.com/questions/442833/how-to-force-driver-to-device-match-in-linux/52943745#52943745
https://unix.stackexchange.com/questions/67936/attaching-usb-serial-device-with-custom-pid-to-ttyusb0-on-embedded/165845#165845
Moreover, to load and configure modules there are /etc/modprobe.d/ and
/etc/modules.
If it is a weird device that may appear either as 13b1:0039 (supported
by brcmfmac accordingly to modinfo) and 13b1:0bdc, may it happen that
it is possible to use e.g. usb-modeswitch to adjust which way the
device tries to present itself?

Those are fair questions. If the appearance of the brcmfmac/ directory
is the sole precondition, then I would probably try udev. But I claim
no knowledge about the module or any device connected with it.

Where cron/sleep is useful is where some device has to settle, or
wait in some way, before the string is sent. One example I use is:

@reboot sleep 15 && printf '\n' > /dev/tty1 && /usr/sbin/rfkill > /dev/tty1 && /usr/bin/ip a > /dev/tty1

which tells me whether the hardware toggle switch on my ancient laptop
is actually unblocked (the switch's indicator lamp is unreliable) and
whether it's connected to the router, and how.

Cheers,
David.

[Max Nikulin]

Post by David Wright

Post by Max Nikulin

Post by David Wright
@reboot sleep 99 && echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

I am in doubts if it is a task for cron. Wouldn't udev rules be better?

Those are fair questions. If the appearance of the brcmfmac/ directory
is the sole precondition, then I would probably try udev. But I claim
no knowledge about the module or any device connected with it.

The /sys/bus/usb/drivers/brcmfmac directory should appear when the
module is loaded. Likely there is no point to load the module if the
device is not plugged, thus udev should be better than /etc/modprobe.d.

Post by David Wright
Where cron/sleep is useful is where some device has to settle, or
@reboot sleep 15 && printf '\n' > /dev/tty1 && /usr/sbin/rfkill > /dev/tty1 && /usr/bin/ip a > /dev/tty1

I would consider a systemd single-shot service that runs after
network.target. Instead of "sleep" I would try either nm-online or
systemd-networkd-wait-online with timeout. I admit, in some cases they
have no advantages over sleep.

[Kamil Jońca]

Gremlin <scott-***@columbus.rr.com> writes:

[...]

Post by Gremlin
https://wiki.archlinux.org/title/Systemd-networkd
https://wiki.archlinux.org/title/Wireless_bonding
I am using systemd-networkd and systemd-resolved and have removed
Networkmanager, ifupdown and isc-dhcp. Also avahi, modemmanager,
openssh-sftp-server openssh-server and openssh-sk-helper

Great. But I think that systemd is still not able to handle my config
(described for example here
https://lists.freedesktop.org/archives/systemd-devel/2022-May/047934.html
)
Recently someone describes problem with proper routing of DNS questions,
when he has VPN connection.

Post by Gremlin
They ain't needed

For you.

When comes to cron and systemd timers.

With cron, regular user can set up his/her jobs wihtout using admin
credentials, and these jobs will be triggered regardless of being logged
in. Is it possible with systemd timers?
KJ

[Andy Smith]

Hi,

Post by Kamil Jońca
With cron, regular user can set up his/her jobs wihtout using admin
credentials, and these jobs will be triggered regardless of being logged
in. Is it possible with systemd timers?

Once you enable lingering for a user, that user's timers will
trigger all the time.

https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances

I haven't yet found anything that I could do with cron that I can't
do with systemd timers, though sometimes the behaviour of cron where
it emails you the output (if any) is very convenient and is tricky
(but not impossible) to replicate with systemd timers.

Thanks,
Andy

[Kamil Jońca]

Post by Andy Smith
Hi,

Post by Kamil Jońca
With cron, regular user can set up his/her jobs wihtout using admin
credentials, and these jobs will be triggered regardless of being logged
in. Is it possible with systemd timers?

Once you enable lingering for a user, that user's timers will
trigger all the time.

IIRC lingered user cannot be "normal" with session and so on. Am I
wrong?

KJ

[Andy Smith]

Hi,

Post by Kamil Jońca

Post by Andy Smith
Once you enable lingering for a user, that user's timers will
trigger all the time.

IIRC lingered user cannot be "normal" with session and so on. Am I
wrong?

How do you mean? On several machines I have linger enabled for my
main user, and timers run when I am not logged in.

Thanks,
Andy

[Kamil Jońca]

Post by Andy Smith
Hi,

Post by Kamil Jońca

Post by Andy Smith
Once you enable lingering for a user, that user's timers will
trigger all the time.

IIRC lingered user cannot be "normal" with session and so on. Am I
wrong?

How do you mean? On several machines I have linger enabled for my
main user, and timers run when I am not logged in.

How precisely linger works? (what it starts? What not etc)
I read about lingering some time ago, and I have had impression
(wrong?) that it may conflict with my normal session.
KJ

[Max Nikulin]

Post by Kamil Jońca
How precisely linger works? (what it starts? What not etc)
I read about lingering some time ago, and I have had impression
(wrong?) that it may conflict with my normal session.

Multiple sessions may be started for a user: DM, ssh, VT logins. I am
unsure what one you consider as your normal session. These sessions run
withing single systemd user service.