Re: where are the crontab files in Trixie?

2024-02-29 Thread Max Nikulin

On 29/02/2024 11:32, David Wright wrote:

On Wed 28 Feb 2024 at 22:32:57 (+0700), Max Nikulin wrote:

On 28/02/2024 10:35, David Wright wrote:

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

@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.



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


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.





Re: where are the crontab files in Trixie?

2024-02-28 Thread David Wright
On Wed 28 Feb 2024 at 22:32:57 (+0700), Max Nikulin wrote:
> On 28/02/2024 10:35, David Wright wrote:
> > In which case, I'd write the remaining cron line as:
> > 
> >@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.



Re: where are the crontab files in Trixie?

2024-02-28 Thread Max Nikulin

On 29/02/2024 00:00, Kamil Jońca wrote:

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.




Re: where are the crontab files in Trixie?

2024-02-28 Thread Kamil Jońca
Andy Smith  writes:

> Hi,
>
> On Wed, Feb 28, 2024 at 04:47:59PM +0100, Kamil Jońca wrote:
>> Andy Smith  writes:
>> > 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



Re: where are the crontab files in Trixie?

2024-02-28 Thread Andy Smith
Hi,

On Wed, Feb 28, 2024 at 04:47:59PM +0100, Kamil Jońca wrote:
> Andy Smith  writes:
> > 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

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: where are the crontab files in Trixie?

2024-02-28 Thread Kamil Jońca
Andy Smith  writes:

> Hi,
>
> On Wed, Feb 28, 2024 at 05:49:58AM +0100, Kamil Jońca wrote:
>> 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



Re: where are the crontab files in Trixie?

2024-02-28 Thread Nicolas George
Max Nikulin (12024-02-28):
> 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,

-- 
  Nicolas George



Re: where are the crontab files in Trixie?

2024-02-28 Thread Max Nikulin

On 28/02/2024 10:35, David Wright wrote:

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

   @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?






Re: where are the crontab files in Trixie?

2024-02-28 Thread Andy Smith
Hi,

On Wed, Feb 28, 2024 at 05:49:58AM +0100, Kamil Jońca wrote:
> 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

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: where are the crontab files in Trixie?

2024-02-28 Thread Andy Smith
Hello,

On Tue, Feb 27, 2024 at 02:58:13PM -0500, Greg Wooledge wrote:
> 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

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: where are the crontab files in Trixie?

2024-02-27 Thread Kamil Jońca
Gremlin  writes:

[...]
>
> 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.

>
> 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



Re: where are the crontab files in Trixie?

2024-02-27 Thread David Wright
On Tue 27 Feb 2024 at 15:35:07 (+), Michael Kjörling wrote:
> On 27 Feb 2024 10:15 -0500, from g...@extremeground.com (Gary Dale):

> 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

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

> _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.

> > 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/.

Note that you won't see the first three lines of crontabs/
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/ will be of little interest.

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

Cheers,
David.



Re: where are the crontab files in Trixie?

2024-02-27 Thread Greg Wooledge
On Tue, Feb 27, 2024 at 10:12:11PM -0500, The Wanderer wrote:
> On 2024-02-27 at 14:09, Gary Dale wrote:
> > 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
   theirowncrontab,andthoughthesearefiles   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.



Re: where are the crontab files in Trixie?

2024-02-27 Thread The Wanderer
On 2024-02-27 at 14:09, Gary Dale wrote:

> On 2024-02-27 10:26, The Wanderer wrote:
>
>> On 2024-02-27 at 10:15, Gary Dale wrote:
>>
>>> 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.)

> 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.)

>>> 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?
>> 
>> The first paragraph of crontab(1) states:
>> 
 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.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: where are the crontab files in Trixie?

2024-02-27 Thread Gremlin

On 2/27/24 14:58, Greg Wooledge wrote:

On Tue, Feb 27, 2024 at 12:52:33PM -0700, Charles Curley wrote:

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


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.

root@hawk:~# systemctl list-units '*cron*'
   UNITLOAD   ACTIVE SUB DESCRIPTION
   cron.serviceloaded 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  PIDPPID  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


--
Hindi madali ang maging ako




Re: where are the crontab files in Trixie?

2024-02-27 Thread Gremlin

On 2/27/24 14:33, Gary Dale wrote:

On 2024-02-27 14:13, Jeffrey Walton wrote:

On Tue, Feb 27, 2024 at 2:12 PM Gary Dale  wrote:

On 2024-02-27 10:25, Kushal Kumaran wrote:
On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale 
 wrote:

[...]
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




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 
 arm64QtWayland client library
ii  libqt5waylandcompositor5:arm64   5.15.8-2 
 arm64QtWayland compositor library
ii  libva-wayland2:arm64 2.17.0-1 
 arm64Video Acceleration (VA) API for Linux -- Wayland runtime
ii  libwayland-client0:arm64 1.21.0-1 
 arm64wayland compositor infrastructure - client library
ii  libwayland-cursor0:arm64 1.21.0-1 
 arm64wayland compositor infrastructure - cursor library
ii  libwayland-egl1:arm641.21.0-1 
 arm64wayland compositor infrastructure - EGL library
ii  libwayland-server0:arm64 1.21.0-1 
 arm64wayland compositor infrastructure - server library
ii  libwlroots11:arm64   0.16.0-2~bpo11+1~rpt13 
 arm64Modular wayland compositor library - shared library
ii  qtwayland5:arm64 5.15.8-2 
 arm64QtWayland platform plugin
ii  xwayland 2:22.1.9-1 
 arm64X server for running X clients under Wayland
ii  wayfire  0.7.5-1~bpo11+1~rpt33 
 arm643D Wayland compositor
ii  wayvnc   0.8.0-rc0-2 
 arm64VNC server for wlroots-based Wayland compositors
ii  xwayland 2:22.1.9-1 
 arm64X server for running X clients under Wayland


ii  lxde-common  0.99.2-4 
 all  LXDE common configuration files
ii  lxde-core11+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


--
If it ain't broke, FIX IT!




Re: where are the crontab files in Trixie?

2024-02-27 Thread Greg Wooledge
On Tue, Feb 27, 2024 at 12:52:33PM -0700, Charles Curley wrote:
> On Tue, 27 Feb 2024 14:13:49 -0500
> Jeffrey Walton  wrote:
> 
> > > 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.
> 
> root@hawk:~# systemctl list-units '*cron*'
>   UNITLOAD   ACTIVE SUB DESCRIPTION   
>   
>   cron.serviceloaded 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  PIDPPID  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.



Re: where are the crontab files in Trixie?

2024-02-27 Thread Charles Curley
On Tue, 27 Feb 2024 14:13:49 -0500
Jeffrey Walton  wrote:

> > 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.

root@hawk:~# systemctl list-units '*cron*'
  UNITLOAD   ACTIVE SUB DESCRIPTION 

  cron.serviceloaded 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'.
root@hawk:~# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/



Re: where are the crontab files in Trixie?

2024-02-27 Thread Gary Dale

On 2024-02-27 14:13, Jeffrey Walton wrote:

On Tue, Feb 27, 2024 at 2:12 PM Gary Dale  wrote:

On 2024-02-27 10:25, Kushal Kumaran wrote:

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

[...]
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.



Re: where are the crontab files in Trixie?

2024-02-27 Thread Jeffrey Walton
On Tue, Feb 27, 2024 at 2:12 PM Gary Dale  wrote:
>
> On 2024-02-27 10:25, Kushal Kumaran wrote:
> > On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale  
> > wrote:
> >> [...]
> >> 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



Re: where are the crontab files in Trixie?

2024-02-27 Thread Gary Dale

On 2024-02-27 10:32, Greg Wooledge wrote:

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

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"

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.


Yep. That works.  Thanks.



Re: where are the crontab files in Trixie?

2024-02-27 Thread Gary Dale

On 2024-02-27 10:25, Kushal Kumaran wrote:

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

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.


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.


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.




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.



Re: where are the crontab files in Trixie?

2024-02-27 Thread Gary Dale

On 2024-02-27 10:26, The Wanderer wrote:

On 2024-02-27 at 10:15, Gary Dale wrote:


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



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?

The first paragraph of crontab(1) states:


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.




Re: where are the crontab files in Trixie?

2024-02-27 Thread Michael Kjörling
On 27 Feb 2024 10:15 -0500, from g...@extremeground.com (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.


> 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.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”



Re: where are the crontab files in Trixie?

2024-02-27 Thread Greg Wooledge
On Tue, Feb 27, 2024 at 10:15:59AM -0500, Gary Dale wrote:
> 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"

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.



Re: where are the crontab files in Trixie?

2024-02-27 Thread The Wanderer
On 2024-02-27 at 10:15, Gary Dale wrote:

> 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.

> 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?

The first paragraph of crontab(1) states:

>> 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.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: where are the crontab files in Trixie?

2024-02-27 Thread Kushal Kumaran
On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale  wrote:
> 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.
>

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.

> 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.

> 
>
> 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.

-- 
regards,
kushal