Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #267907 > unrolled thread

where are the crontab files in Trixie?

Back to article view | Back to linux.debian.user

Contents

  where are the crontab files in Trixie? Gary Dale <gary@extremeground.com> - 2024-02-27 16:20 +0100
    Re: where are the crontab files in Trixie? The Wanderer <wanderer@fastmail.fm> - 2024-02-27 16:30 +0100
      Re: where are the crontab files in Trixie? Gary Dale <gary@extremeground.com> - 2024-02-27 20:20 +0100
        Re: where are the crontab files in Trixie? Greg Wooledge <greg@wooledge.org> - 2024-02-28 04:20 +0100
        Re: where are the crontab files in Trixie? The Wanderer <wanderer@fastmail.fm> - 2024-02-28 04:20 +0100
    Re: where are the crontab files in Trixie? Kushal Kumaran <kushal@locationd.net> - 2024-02-27 16:30 +0100
      Re: where are the crontab files in Trixie? Gary Dale <gary@extremeground.com> - 2024-02-27 20:20 +0100
        Re: where are the crontab files in Trixie? Jeffrey Walton <noloader@gmail.com> - 2024-02-27 20:20 +0100
          Re: where are the crontab files in Trixie? Gary Dale <gary@extremeground.com> - 2024-02-27 20:40 +0100
            Re: where are the crontab files in Trixie? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-27 22:10 +0100
          Re: where are the crontab files in Trixie? Charles Curley <charlescurley@charlescurley.com> - 2024-02-27 21:00 +0100
            Re: where are the crontab files in Trixie? Greg Wooledge <greg@wooledge.org> - 2024-02-27 21:00 +0100
              Re: where are the crontab files in Trixie? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-27 22:20 +0100
              Re: where are the crontab files in Trixie? Andy Smith <andy@strugglers.net> - 2024-02-28 16:10 +0100
    Re: where are the crontab files in Trixie? Greg Wooledge <greg@wooledge.org> - 2024-02-27 16:40 +0100
      Re: where are the crontab files in Trixie? Gary Dale <gary@extremeground.com> - 2024-02-27 20:20 +0100
    Re: where are the crontab files in Trixie? Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-02-27 16:40 +0100
      Re: where are the crontab files in Trixie? David Wright <deblis@lionunicorn.co.uk> - 2024-02-28 04:40 +0100
        Re: where are the crontab files in Trixie? Max Nikulin <manikulin@gmail.com> - 2024-02-28 16:40 +0100
          Re: where are the crontab files in Trixie? Nicolas George <george@nsup.org> - 2024-02-28 17:00 +0100
          Re: where are the crontab files in Trixie? David Wright <deblis@lionunicorn.co.uk> - 2024-02-29 05:40 +0100
            Re: where are the crontab files in Trixie? Max Nikulin <manikulin@gmail.com> - 2024-02-29 16:20 +0100

Page 1 of 2  [1] 2  Next page →

#267907 — where are the crontab files in Trixie?

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?

[toc] | [next] | [standalone]

#267908

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#267914

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.

[toc] | [prev] | [next] | [standalone]

#267928

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

[toc] | [prev] | [next] | [standalone]

#267929

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#267909

On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale <gary@extremeground.com> 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.

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

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#267913

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

[toc] | [prev] | [next] | [standalone]

#267916

On Tue, Feb 27, 2024 at 2:12 PM Gary Dale <gary@extremeground.com> wrote:
>
> On 2024-02-27 10:25, Kushal Kumaran wrote:
> > On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale <gary@extremeground.com> 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

[toc] | [prev] | [next] | [standalone]

#267917

On 2024-02-27 14:13, Jeffrey Walton wrote:
> On Tue, Feb 27, 2024 at 2:12 PM Gary Dale <gary@extremeground.com> wrote:
>> On 2024-02-27 10:25, Kushal Kumaran wrote:
>>> On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale <gary@extremeground.com> 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.

[toc] | [prev] | [next] | [standalone]

#267921

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

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

[toc] | [prev] | [next] | [standalone]

#267918

On Tue, 27 Feb 2024 14:13:49 -0500
Jeffrey Walton <noloader@gmail.com> 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*'
  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'.
root@hawk:~# 


-- 
Does anybody read signatures any more?

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

[toc] | [prev] | [next] | [standalone]

#267919

On Tue, Feb 27, 2024 at 12:52:33PM -0700, Charles Curley wrote:
> On Tue, 27 Feb 2024 14:13:49 -0500
> Jeffrey Walton <noloader@gmail.com> 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*'
>   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.

[toc] | [prev] | [next] | [standalone]

#267923

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 <noloader@gmail.com> 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*'
>>    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


-- 
Hindi madali ang maging ako

[toc] | [prev] | [next] | [standalone]

#267935

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

[toc] | [prev] | [next] | [standalone]

#267910

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.

[toc] | [prev] | [next] | [standalone]

#267915

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.

[toc] | [prev] | [next] | [standalone]

#267911

On 27 Feb 2024 10:15 -0500, from gary@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?”

[toc] | [prev] | [next] | [standalone]

#267930

On Tue 27 Feb 2024 at 15:35:07 (+0000), Michael Kjörling wrote:
> On 27 Feb 2024 10:15 -0500, from gary@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/<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.

[toc] | [prev] | [next] | [standalone]

#267937

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?

[toc] | [prev] | [next] | [standalone]

#267938

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web