Re: unwanted crontab message

[Michael Kjörling]

On 13 Sep 2024 17:53 -0400, from g...@wooledge.org (Greg Wooledge):
> For the record, Debian 12 has vim 9.0.x and a /usr/share/vim/vim90/
> directory.  According to ... oh,
> that web page is not responding for me.  Sorry, I can't check what
> version(s) of Debian might have had vim 8.2.

Bullseye / 11 had vim 8.2. (Specifically, the current package version
is 2:8.2.2434-3+deb11u1 .)

Buster had 8.1, Bookworm is at 9.0 as you say, and Trixie and Sid are
both currently on the 9.1 branch.

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

Re: unwanted crontab message

[Greg Wooledge]

On Fri, Sep 13, 2024 at 22:46:09 +, Andy Smith wrote:
> I just ran crontab -e as a fresh user and it actually invoked
> /usr/bin/sensible-editor and asked me which editor I wanted to use
> (now and in future). So perhaps the man page for crontab is out of
> date.

Agreed.

hobbit:~$ strings /usr/bin/crontab | grep usr/bin/
/usr/bin/sensible-editor

The man page is simply wrong, I think.

Re: unwanted crontab message

[Will Mengarini]

Or ... disambiguate which Vim crontab -e is using, so it's not vim.tiny.

* Will Mengarini  [24-09/13=Fri 15:47 -0700]:
> You are getting Vim error messages from a version of Vim that does
> not support scripting (probably vim.tiny).  That version is probably
> installed on your system ALONG WITH a version that does support
> scripting, but cron does not have the scripting version of Vim on PATH.
> (Typically, your $HOME & root PATHs are more elaborate than the one to
> which cron defaults.)  The solution is to set PATH in your crontab.
>
> * Marcus Park  [24-09/14=Sat 06:12 +0800]:
> >
> > Andy Smith :
> >> As to why whatever it is set as right now is doing that, first work
> >> out where it is getting the setting from, so echo $EDITOR and echo
> >> $VISUAL. If neither of those are set then ls -la /usr/bin/editor.
> >
> > Thanks Andy.
> >
> > either $EDITOR or $VISUAL in my system is empty.
> >
> > And /usr/bin/editor points to nano.
> >
> > Then I run this command,
> >
> > $ sudo update-alternatives --config editor
> > There are 4 choices for the alternative editor (providing /usr/bin/editor).
> >
> >   SelectionPathPriority   Status
> > 
> > * 0/bin/nano40auto mode
> >   1/bin/ed -100   manual mode
> >   2/bin/nano40manual mode
> >   3/usr/bin/vim.basic   30manual mode
> >   4/usr/bin/vim.tiny15manual mode
> >
> > Press  to keep the current choice[*], or type selection number: 3
> > update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor
> > (editor) in manual mode
> >
> >
> >
> > to choose vim.basic as default editor.
> >
> > In my system both vim.basic and vim are the same stuff,
> >
> > $ vim --version
> > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> > Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> > 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> > 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> > 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> > 1846-1847, 2110-2112, 2121
> > ...
> >
> >
> > $ vim.basic --version
> > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> > Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> > 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> > 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> > 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> > 1846-1847, 2110-2112, 2121
> > ...
> >
> >
> > Then I logged out and re-login the system, run 'crontab -e', the error still
> > shows. Maybe I got bad luck today. :(
> >
> > Regards.

Re: unwanted crontab message

[Will Mengarini]

You are getting Vim error messages from a version of Vim that does
not support scripting (probably vim.tiny).  That version is probably
installed on your system ALONG WITH a version that does support
scripting, but cron does not have the scripting version of Vim on PATH.
(Typically, your $HOME & root PATHs are more elaborate than the one to
which cron defaults.)  The solution is to set PATH in your crontab.

* Marcus Park  [24-09/14=Sat 06:12 +0800]:
>
> Andy Smith :
>> As to why whatever it is set as right now is doing that, first work
>> out where it is getting the setting from, so echo $EDITOR and echo
>> $VISUAL. If neither of those are set then ls -la /usr/bin/editor.
>
> Thanks Andy.
>
> either $EDITOR or $VISUAL in my system is empty.
>
> And /usr/bin/editor points to nano.
>
> Then I run this command,
>
> $ sudo update-alternatives --config editor
> There are 4 choices for the alternative editor (providing /usr/bin/editor).
>
>   SelectionPathPriority   Status
> 
> * 0/bin/nano40auto mode
>   1/bin/ed -100   manual mode
>   2/bin/nano40manual mode
>   3/usr/bin/vim.basic   30manual mode
>   4/usr/bin/vim.tiny15manual mode
>
> Press  to keep the current choice[*], or type selection number: 3
> update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor
> (editor) in manual mode
>
>
>
> to choose vim.basic as default editor.
>
> In my system both vim.basic and vim are the same stuff,
>
> $ vim --version
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> 1846-1847, 2110-2112, 2121
> ...
>
>
> $ vim.basic --version
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
> Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975,
> 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859,
> 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108,
> 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840,
> 1846-1847, 2110-2112, 2121
> ...
>
>
> Then I logged out and re-login the system, run 'crontab -e', the error still
> shows. Maybe I got bad luck today. :(
>
> Regards.

Re: unwanted crontab message

[Andy Smith]

Hi,

On Sat, Sep 14, 2024 at 06:12:02AM +0800, Marcus Park wrote:
> either $EDITOR or $VISUAL in my system is empty.
> 
> And /usr/bin/editor points to nano.

Well, I do not really understand what is going on then as you are
definitely running an editor that looks at vim config files, and
nano won't do that.

I assume you are looking at the environment of the same user that is
executing "crontab -e"?

When the editor from "crontab -e" is running, you could go into
another terminal and look at all your processes to see which actual
binary is being called. IIRC, vim when invoked as vi, acts in vi
compat mode and that may be why it can't parse its own system
config. Although still it is a mystery to me why you do not get
nano.

I just ran crontab -e as a fresh user and it actually invoked
/usr/bin/sensible-editor and asked me which editor I wanted to use
(now and in future). So perhaps the man page for crontab is out of
date. It seems that sensible-editor records this choice in
~/.selected_editor. Is this what got called for you? If so,
apparently running "select-editor" will change the choice.

Thanks,
Andy

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

Re: scp in crontab problem

[Marcus Park]

basti:

/usr/bin/scp -i /home/userYX/.ssh/myKEY r...@example.com ...



updated: it's really due to environment issue, after I add the '-i' path 
to scp, jobs run well now.


Thanks basti.

Re: unwanted crontab message

[Marcus Park]

Andy Smith :

As to why whatever it is set as right now is doing that, first work
out where it is getting the setting from, so echo $EDITOR and echo
$VISUAL. If neither of those are set then ls -la /usr/bin/editor.



Thanks Andy.

either $EDITOR or $VISUAL in my system is empty.

And /usr/bin/editor points to nano.

Then I run this command,

$ sudo update-alternatives --config editor
There are 4 choices for the alternative editor (providing /usr/bin/editor).

  SelectionPathPriority   Status

* 0/bin/nano40auto mode
  1/bin/ed -100   manual mode
  2/bin/nano40manual mode
  3/usr/bin/vim.basic   30manual mode
  4/usr/bin/vim.tiny15manual mode

Press  to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor 
(editor) in manual mode




to choose vim.basic as default editor.

In my system both vim.basic and vim are the same stuff,

$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975, 
5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 
1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 
2069-2106, 2108, 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 
4901, 4919, 213, 1840, 1846-1847, 2110-2112, 2121

...


$ vim.basic --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 27 2024 05:34:22)
Included patches: 1-16, 647, 17-579, 1969, 580-647, 678, 648-1848, 4975, 
5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 
1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 
2069-2106, 2108, 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 
4901, 4919, 213, 1840, 1846-1847, 2110-2112, 2121

...


Then I logged out and re-login the system, run 'crontab -e', the error 
still shows. Maybe I got bad luck today. :(


Regards.

Re: unwanted crontab message

[Andy Smith]

Hi,

On Sat, Sep 14, 2024 at 05:44:42AM +0800, Marcus Park wrote:
> When I run 'crontab -e' the screen shows some errors like,
> 
> $ crontab -e
> Error detected while processing /usr/share/vim/vim82/filetype.vim:

I'm pretty sure that these errors will be coming from the editor
binary that is set in your VISUAL or EDITOR environment variables,
or failing thatm whatever /usr/bin/editor points at.

man crontab

The  -e option is used to edit the current crontab using the
editor specified by the VISUAL or EDITOR environ‐ ment
variables.  After you exit from the editor, the modified crontab
will  be  installed  automatically.   If neither of the
environment variables is defined, then the default editor
/usr/bin/editor is used.

> how to fix up it?

Set EDITOR or VISUAL to an editor that works.

export EDITOR=nano

or whatever you prefer.

As to why whatever it is set as right now is doing that, first work
out where it is getting the setting from, so echo $EDITOR and echo
$VISUAL. If neither of those are set then ls -la /usr/bin/editor.

I'll guess that you have vim-tiny or some other very minimal vi
clone installed but still somehow have vim-runtime installed and
it's trying to use that while not being able to parse it.

So either use a different editor or fix that editor or remove
vim-runtime, I suppose.

Thanks,
Andy

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

Re: unwanted crontab message

[Greg Wooledge]

On Sat, Sep 14, 2024 at 05:44:42 +0800, Marcus Park wrote:
> Hi list,
> 
> When I run 'crontab -e' the screen shows some errors like,
> 
> $ crontab -e
> Error detected while processing /usr/share/vim/vim82/filetype.vim:
> line   10:
> E319: Sorry, the command is not available in this version: let
> did_load_filetypes = 1

What version of Debian is this?

What version of the vim package (or any similarly named package) are
you running?

Did you do anything *noteworthy* with this system, such as attempting
an upgrade from one version of Debian to another, having it fail, and
leaving it half done?

For the record, Debian 12 has vim 9.0.x and a /usr/share/vim/vim90/
directory.  According to <https://packages.debian.org/vim>... oh,
that web page is not responding for me.  Sorry, I can't check what
version(s) of Debian might have had vim 8.2.

Anyway, it sounds like you have vim 8.2 config files, but you're running
an *older* version of vim which can't read those configs.  Either that,
or the /usr/share/vim/vim82/filetype.vim file is corrupted.  If it's
a corrupted file, you could purge and reinstall the vim package(s).

unwanted crontab message

[Marcus Park]

Hi list,

When I run 'crontab -e' the screen shows some errors like,

$ crontab -e
Error detected while processing /usr/share/vim/vim82/filetype.vim:
line   10:
E319: Sorry, the command is not available in this version: let 
did_load_filetypes = 1

line   13:
E319: Sorry, the command is not available in this version: let 
s:cpo_save = &cpo

line   47:
E319: Sorry, the command is not available in this version: func! 
s:StarSetf(ft)

line   51:
E319: Sorry, the command is not available in this version: endfunc
line 2440:
E319: Sorry, the command is not available in this version: func! 
TestFiletypeFuncs(testlist)

line 2441:
E319: Sorry, the command is not available in this version:   let output = ''
line 2442:
E319: Sorry, the command is not available in this version:   for f in 
a:testlist

... (and many other lines)

how to fix up it?

Thanks.

Re: scp in crontab problem

[Charles Curley]

On Fri, 13 Sep 2024 20:24:51 +0800
Marcus Park  wrote:

> Hi list,
> 
> I have put the private key into my debian VPS (in ~/.ssh/ dir).

The private key of what?

And to ~/.ssh/ on which computer. you are talking about transferring a
file from one computer to another; which one?

And why the private key? Usually one transfers the public key from
one's own computer to another, and one keeps the private key, well,
private.

> 
> When I scp a file from this VPS to another one by hand without
> password, it works.
> 
> But when I put this scp into crontab, it seems not work. The scp in 
> crontab via private key didn't run as I expect, nothing was copied to
> peer.

Don't tell us what you did, show us. Copy exactly the line(s) from your
crontab file and paste it into your email.

Did you get an email from cron? If so, show us that.

> 
> Can you help?

Not without better information.

-- 
Does anybody read signatures any more?

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

Re: scp in crontab problem

[Greg Wooledge]

On Fri, Sep 13, 2024 at 20:24:51 +0800, Marcus Park wrote:
> I have put the private key into my debian VPS (in ~/.ssh/ dir).

Does this private key have a passphrase?

> When I scp a file from this VPS to another one by hand without password, it
> works.
> 
> But when I put this scp into crontab, it seems not work. The scp in crontab
> via private key didn't run as I expect, nothing was copied to peer.

First question: what did the output say?  Any output from the cron job
should have been mailed to you.  If you don't have a mail reader set up
on this machine, try "less /var/mail/$LOGNAME" or something.  If you
don't have local mail delivery set up, fix that.

Second question: if the key has a passphrase, are you using an ssh-agent
to invoke it normally?  The cron job won't have access to your ssh-agent,
not without a bunch of additional setup.

For automated jobs, you usually need the private key to NOT have a
passphrase.  And yes, this is a large security concern.  You'll have
to balance your security needs against your application needs.

Re: scp in crontab problem

[basti]

On 13.09.24 14:24, Marcus Park wrote:

Hi list,

I have put the private key into my debian VPS (in ~/.ssh/ dir).

When I scp a file from this VPS to another one by hand without password, 
it works.


But when I put this scp into crontab, it seems not work. The scp in 
crontab via private key didn't run as I expect, nothing was copied to peer.


Can you help?

Thank you.
Marcus



Cron doesn't know anything about your environment variables.
You can set PATH or HOME or use absolute paths.

/usr/bin/scp -i /home/userYX/.ssh/myKEY r...@example.com ...

Best regards,

scp in crontab problem

[Marcus Park]

Hi list,

I have put the private key into my debian VPS (in ~/.ssh/ dir).

When I scp a file from this VPS to another one by hand without password, 
it works.


But when I put this scp into crontab, it seems not work. The scp in 
crontab via private key didn't run as I expect, nothing was copied to peer.


Can you help?

Thank you.
Marcus

Re: where are the crontab files in Trixie?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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?

Re: auto restarting in crontab

[debian-user]

"p...@ymail.ne.jp"  wrote:
> debian-u...@howorth.org.uk wrote:
> > But it sounds like what...@ymail.ne.jp  is doing isn't best practice
> > either, although I don't fully understand what they mean by "I often
> > change default ruby in interactive shell". If they mean 'global'
> > then I suspect they should be using 'local' instead. Or just
> > possibly 'shell'.  
> 
> I installed ruby only in my personal account, not the global.
> Sometimes I was using the older ruby version (1.x), but sometimes I
> am using the latest ruby (3.x). For example, different streaming
> libraries for ruby require different versions.
> 
> For instance, I developed a ruby client for Kafka streaming, and 
> deployed it in crontab, and this script must use ruby 3.x version.
> 
> 0 * * * * ruby kafka-consumer.rb
> 
> But one day I changed the default version in my personal path to ruby 
> 1.x via rbenv, the crontab above should not work. This is a risk, is
> it?

You're using terms I don't recognize from my brief reading of the docs.
But it seems you're doing things that I don't see mentioned there, and
that you have older ruby versions that I don't expect to see. So I
suggest reading the docs and trying to follow them. I believe your
kafka-consumer should be set up with rbenv local so it doesn't matter
what you say in the crontab.

> regards
> Yong

Re: auto restarting in crontab

[Nicolas George]

debian-u...@howorth.org.uk (12023-03-17):
> Please don't send me an individual copy of emails; I am subscribed.

Nobody can remember who is subscribed and who is not: do not write this
in your mail, write it in the headers, just like I did.

-- 
  Nicolas George

Re: auto restarting in crontab

[debian-user]

Please don't send me an individual copy of emails; I am subscribed.

Dan Ritter  wrote:
> debian-u...@howorth.org.uk wrote: 
> > Dan Ritter  wrote:  
> > > p...@ymail.ne.jp wrote:   
> > > > For dev stuff, for example, I have many versions of ruby
> > > > installed in the system by rbenv.
> > > > 
> > > > Since I often change default ruby in interactive shell, this may
> > > > break the ruby for sysadmin job in crontab. What’s the solution
> > > > for this?  
> > > 
> > > Everywhere it matters, set an explicit PATH at the beginning.
> > > 
> > > There is no other solution.  
> > 
> > Err, I know nothing about the subject but that doesn't seem to
> > correspond with what it says in the readme at
> > https://github.com/rbenv/rbenv  
> 
> rbenv is a fancy way of setting the PATH. It changes out setting
> the PATH directly for requiring you to set up a .ruby-version
> file for every project. If you commit to it, it might be better
> for you. If you don't, it's harder to debug what's going wrong.

The point is that the OP said they were using rbenv, so that's what
matters to them. That's what they've chosen.

> In general, development environments might want multiple Ruby
> versions but production should only have one. If the production
> version isn't the one that Debian is currently shipping, the
> Debian-shipped version shouldn't be installed at all.
> 
> -dsr-

Re: auto restarting in crontab

[Greg Wooledge]

On Fri, Mar 17, 2023 at 08:04:24AM +0800, p...@ymail.ne.jp wrote:
> Sometimes I was using the older ruby version (1.x), but sometimes I am using
> the latest ruby (3.x). For example, different streaming libraries for ruby
> require different versions.
> 
> For instance, I developed a ruby client for Kafka streaming, and deployed it
> in crontab, and this script must use ruby 3.x version.
> 
> 0 * * * * ruby kafka-consumer.rb

How is cron going to know which ruby to use?  Cron uses a very minimalist
PATH.  From crontab(5):

   Several environment variables are set up automatically by  the  cron(8)
   daemon.  SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
   /etc/passwd  line  of  the   crontab's   owner.PATH   is   set   to
   "/usr/bin:/bin".   HOME,  SHELL, and PATH may be overridden by settings
   in the crontab; LOGNAME is the user that the job is running  from,  and
   may not be changed.

Cron is going to look for /usr/bin/ruby or /bin/ruby and that's it,
unless there's more to this crontab that you haven't shown us.

If you need your crontab to use a specific version of ruby, on a system
with multiple versions installed, you need to use the full path to one
of them, or set the PATH variable.

Re: auto restarting in crontab

[p...@ymail.ne.jp]

debian-u...@howorth.org.uk wrote:

But it sounds like what...@ymail.ne.jp  is doing isn't best practice
either, although I don't fully understand what they mean by "I often
change default ruby in interactive shell". If they mean 'global' then I
suspect they should be using 'local' instead. Or just possibly 'shell'.


I installed ruby only in my personal account, not the global.
Sometimes I was using the older ruby version (1.x), but sometimes I am 
using the latest ruby (3.x). For example, different streaming libraries 
for ruby require different versions.


For instance, I developed a ruby client for Kafka streaming, and 
deployed it in crontab, and this script must use ruby 3.x version.


0 * * * * ruby kafka-consumer.rb

But one day I changed the default version in my personal path to ruby 
1.x via rbenv, the crontab above should not work. This is a risk, is it?


regards
Yong

Re: auto restarting in crontab

[Jeffrey Walton]

On Thu, Mar 16, 2023 at 7:03 PM Dan Ritter  wrote:
>
> debian-u...@howorth.org.uk wrote:
> > Dan Ritter  wrote:
> > > p...@ymail.ne.jp wrote:
> > > > For dev stuff, for example, I have many versions of ruby installed
> > > > in the system by rbenv.
> > > >
> > > > Since I often change default ruby in interactive shell, this may
> > > > break the ruby for sysadmin job in crontab. What’s the solution for
> > > > this?
> > >
> > > Everywhere it matters, set an explicit PATH at the beginning.
> > >
> > > There is no other solution.
> >
> > Err, I know nothing about the subject but that doesn't seem to
> > correspond with what it says in the readme at
> > https://github.com/rbenv/rbenv
>
> rbenv is a fancy way of setting the PATH. It changes out setting
> the PATH directly for requiring you to set up a .ruby-version
> file for every project. If you commit to it, it might be better
> for you. If you don't, it's harder to debug what's going wrong.
>
> In general, development environments might want multiple Ruby
> versions but production should only have one. If the production
> version isn't the one that Debian is currently shipping, the
> Debian-shipped version shouldn't be installed at all.

Likely this. Debian removed update-alternatives for Ruby; see [1]. And
from [1] under "Installing Ruby versions not packaged in Debian":

While ruby-build is a great tool to build Ruby versions
that are not available via APT, you should still use the
Debian-packaged versions of Ruby whenever possible since
they are tested and supported by the Debian community.

[1] https://wiki.debian.org/Ruby

Jeff

Re: auto restarting in crontab

[Dan Ritter]

debian-u...@howorth.org.uk wrote: 
> Dan Ritter  wrote:
> > p...@ymail.ne.jp wrote: 
> > > For dev stuff, for example, I have many versions of ruby installed
> > > in the system by rbenv.
> > > 
> > > Since I often change default ruby in interactive shell, this may
> > > break the ruby for sysadmin job in crontab. What’s the solution for
> > > this?
> > 
> > Everywhere it matters, set an explicit PATH at the beginning.
> > 
> > There is no other solution.
> 
> Err, I know nothing about the subject but that doesn't seem to
> correspond with what it says in the readme at
> https://github.com/rbenv/rbenv

rbenv is a fancy way of setting the PATH. It changes out setting
the PATH directly for requiring you to set up a .ruby-version
file for every project. If you commit to it, it might be better
for you. If you don't, it's harder to debug what's going wrong.

In general, development environments might want multiple Ruby
versions but production should only have one. If the production
version isn't the one that Debian is currently shipping, the
Debian-shipped version shouldn't be installed at all.

-dsr-

Re: auto restarting in crontab

[debian-user]

Dan Ritter  wrote:
> p...@ymail.ne.jp wrote: 
> > For dev stuff, for example, I have many versions of ruby installed
> > in the system by rbenv.
> > 
> > Since I often change default ruby in interactive shell, this may
> > break the ruby for sysadmin job in crontab. What’s the solution for
> > this?
> 
> Everywhere it matters, set an explicit PATH at the beginning.
> 
> There is no other solution.

Err, I know nothing about the subject but that doesn't seem to
correspond with what it says in the readme at
https://github.com/rbenv/rbenv

But it sounds like what p...@ymail.ne.jp is doing isn't best practice
either, although I don't fully understand what they mean by "I often
change default ruby in interactive shell". If they mean 'global' then I
suspect they should be using 'local' instead. Or just possibly 'shell'.

> -dsr-

Re: auto restarting in crontab

[Jude DaShiell]

I tried installing task-lxqt-desktop using apt and that didn't go well at
all.  Since I use a screen reader I ended up installing bullseye mate with
the installation disc then upgrading to bookworm.  That worked.  So far as
I can tell, a11y work was not done on lxqt to bring up orca if speakup got
used during an install.  I was curious as to differences between mate and
lxqt which is why I tried the install.


Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Thu, 16 Mar 2023, Dan Ritter wrote:

> p...@ymail.ne.jp wrote:
> > For dev stuff, for example, I have many versions of ruby installed in the 
> > system by rbenv.
> >
> > Since I often change default ruby in interactive shell, this may break the 
> > ruby for sysadmin job in crontab. What?s the solution for this?
>
>
> Everywhere it matters, set an explicit PATH at the beginning.
>
> There is no other solution.
>
> -dsr-
>
>

Re: auto restarting in crontab

[Dan Ritter]

p...@ymail.ne.jp wrote: 
> For dev stuff, for example, I have many versions of ruby installed in the 
> system by rbenv.
> 
> Since I often change default ruby in interactive shell, this may break the 
> ruby for sysadmin job in crontab. What’s the solution for this?


Everywhere it matters, set an explicit PATH at the beginning.

There is no other solution.

-dsr-

Re: Re: auto restarting in crontab

[pyh]

For dev stuff, for example, I have many versions of ruby installed in the 
system by rbenv.

Since I often change default ruby in interactive shell, this may break the ruby 
for sysadmin job in crontab. What’s the solution for this?

Re: auto restarting in crontab

[Nicolas George]

Greg Wooledge (12023-03-16):
>   So they installed
> parallel toolsets (commands including ps, echo, and so on) in two
> different directories.

Four: there is also /usr/xpg4/bin and /usr/xpg6/bin.

Regards,

-- 
  Nicolas George

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 01:57:26PM +0100, Christoph Brinkhaus wrote:
> I think you are right. The only remaining argument for specifying the
> complete path I have read about is as below.
> There might be the situation with different binaries but similar
> names. For example /usr/bin/nc is different to /bin/nc.
> But such a system should be a nightmare and I doubt if you can find
> such an installation in the wild.

This reminds me of Solaris.  As a successor to the BSD-ish SunOS, Solaris
(which is a System V-ish operating system) wanted to retain some
compatibility with its company's former product.  So they installed
parallel toolsets (commands including ps, echo, and so on) in two
different directories.  The SysV-ish command set, which is the preferred
one going forward, is in /usr/bin.  The BSD-ish command set, the legacy
one, is in /usr/ucb.

Users who want a BSD-ish experience (or scripts relying on that toolset)
are encouraged to make sure /usr/ucb appears before /usr/bin in their
PATH variables.  Users who want the new SysV-ish experience should do
the opposite, or not include /usr/ucb at all.

Re: auto restarting in crontab

[Christoph Brinkhaus]

Am Thu, Mar 16, 2023 at 07:27:22AM -0400 schrieb Greg Wooledge:
> On Thu, Mar 16, 2023 at 12:24:10PM +0100, Christoph Brinkhaus wrote:
> > The environments of login shells and crontab can be different. This
> > includes the path where to seek executables. Therefore it is good
> > practice not to write just the name of the executable as nc but the
> > name with the path as /usr/bin/nc. Here I took nc as an example.
> 
> It's better to set the PATH variable to whatever you need it to be.
> Then you don't have to hard-code the execution path of every single
> command in the script.  (Which means your script breaks when you move
> it to a system where nc is in /bin instead of /usr/bin, and so on.)
> 
I think you are right. The only remaining argument for specifying the
complete path I have read about is as below.
There might be the situation with different binaries but similar
names. For example /usr/bin/nc is different to /bin/nc.
But such a system should be a nightmare and I doubt if you can find
such an installation in the wild.

I have a few scripts which should run at Linux and FreeBSD. In the
past I have used uname to distinguish the platforms. This works but it
is bulky and ugly. Things will be fine if I concat the PATH required
for both systems and follow your advise.

Thank you and kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 12:24:10PM +0100, Christoph Brinkhaus wrote:
> The environments of login shells and crontab can be different. This
> includes the path where to seek executables. Therefore it is good
> practice not to write just the name of the executable as nc but the
> name with the path as /usr/bin/nc. Here I took nc as an example.

It's better to set the PATH variable to whatever you need it to be.
Then you don't have to hard-code the execution path of every single
command in the script.  (Which means your script breaks when you move
it to a system where nc is in /bin instead of /usr/bin, and so on.)

Re: auto restarting in crontab

[Christoph Brinkhaus]

Am Thu, Mar 16, 2023 at 08:55:54AM +0800 schrieb cor...@free.fr:
> Greetings,
> 
> My script for monitoring Node.js app as follows. I put it in crontab for
> auto-check and restart if failure.
> 
> #!/bin/bash
> 
> # scan the port
> nc -z 127.0.0.1 3000
> 
> if [ $? -eq 0 ];then
>   exit
> else
>   killall node
>   sleep 1
>   nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
> fi
> 
> 
> I can run the script by manual, but in crontab it won't work. that means,
> when node.js dies, it will not get restarted by this script automatically.
> 
The environments of login shells and crontab can be different. This
includes the path where to seek executables. Therefore it is good
practice not to write just the name of the executable as nc but the
name with the path as /usr/bin/nc. Here I took nc as an example.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: auto restarting in crontab

[Nicolas George]

Greg Wooledge (12023-03-16):
> That assumes you want to detach the process from its session in the
> first place.  It's NOT what you should do when running a managed
> service, though.
> 
> With a managed service, you don't want ANY of the old legacy "I want
> to run a daemon from an interactive shell and have it automatically
> separate itself from the interactive session" rubbish.

Indeed. But in the rare cases you want that rubbish, DO NOT USE nuhup.

Regards,

-- 
  Nicolas George

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 08:53:55AM +0100, Nicolas George wrote:
> cor...@free.fr (12023-03-16):
> >   nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
> 
> What Greg said. Plus:
> 
> Never use nohup. nohup should never have been invented, it is based on a
> complete lack of understanding of how sessions and control terminal
> work.
> 
> Instead:
> 
> - use setsid to detach the process from the session;
> 
> - explicitly redirect the input and outputs where you want them.

That assumes you want to detach the process from its session in the
first place.  It's NOT what you should do when running a managed
service, though.

With a managed service, you don't want ANY of the old legacy "I want
to run a daemon from an interactive shell and have it automatically
separate itself from the interactive session" rubbish.  You DON'T
want the daemon to fork a background child and abandon it.  You DON'T
want the daemon's output to be discarded, or automatically redirected
to some file.

The service manager needs the daemon to behave sensibly, at least in
systemd's "simple" case.  A single process, with output going to stdout
and/or stderr.  The manager will take care of grabbing the output and
logging it.

Re: auto restarting in crontab

[Nicolas George]

cor...@free.fr (12023-03-16):
>   nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &

What Greg said. Plus:

Never use nohup. nohup should never have been invented, it is based on a
complete lack of understanding of how sessions and control terminal
work.

Instead:

- use setsid to detach the process from the session;

- explicitly redirect the input and outputs where you want them.

Regards,

-- 
  Nicolas George

Re: auto restarting in crontab

[coreyh]

updated: Thanks for all your helps, especially @Greg and @Yong

Now this systemd service has been enabled and just works.
I put a file on /etc/systemd/system/xxx.service whose content as,

[Unit]
Description=xxx Front
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=5
User=corey
Group=corey
ExecStart=serve -s /home/corey/workspace/xxx-frontend/build

[Install]
WantedBy=multi-user.target


And run "systemctl enable xxx.service" then "systemctl start 
xxx.service", and it works perfectly.


regards,
Corey

Re: auto restarting in crontab

[Jeremy Ardley]

On 16/3/23 12:09, p...@ymail.ne.jp wrote:
Just for fun, I asked this question on ChatGPT, who gives the answers 
as follows.


Q:  Please help generate a systemd configuration for Debian linux

A: Sure, here's an example of a systemd configuration file for a 
Debian Linux service:


Be very careful of ChatGPT4.0 it makes many more errors than ChatGPT3.5 
and seems to have less memory of past questions but makes up for it by 
being very wordy and slow.


Most cases today I get a general gist from it but have to go reliable 
sources for an actual implementation



--
Jeremy
(Lists)

Re: auto restarting in crontab

[p...@ymail.ne.jp]

Just for fun, I asked this question on ChatGPT, who gives the answers as 
follows.


Q:  Please help generate a systemd configuration for Debian linux

A: Sure, here's an example of a systemd configuration file for a Debian 
Linux service:


```
[Unit]
Description=My Service
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=5s
ExecStart=/usr/bin/my-service

[Install]
WantedBy=multi-user.target
```

In this example, replace `My Service` with the name of your service, and 
`/usr/bin/my-service` with the path to your service's executable.


Save this file with a `.service` extension, for example, 
`my-service.service`, and place it in the `/etc/systemd/system` directory.


Then, enable the service using the following command:

```
systemctl enable my-service.service
```

This will cause the service to start automatically at boot time.

You can start, stop, and restart the service using the following commands:

```
systemctl start my-service.service
systemctl stop my-service.service
systemctl restart my-service.service
```

You can also view the logs of the service using the following command:

```
journalctl -u my-service.service
```

This will show the logs for your service.

Thanks
Yong

p...@ymail.ne.jp wrote:



cor...@free.fr wrote:

where will I setup this script for systemd job? any reference?


You might look at this article as well.
https://linuxhandbook.com/create-systemd-services/

Yong

Re: auto restarting in crontab

[p...@ymail.ne.jp]

cor...@free.fr wrote:

where will I setup this script for systemd job? any reference?


You might look at this article as well.
https://linuxhandbook.com/create-systemd-services/

Yong

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 09:40:48AM +0800, cor...@free.fr wrote:
> On 16/03/2023 09:32, Greg Wooledge wrote:
> > If that's more than you want to tackle, and if all you want is
> > automatic restarting (not the ability to stop it at will), then this
> > should suffice:
> > 
> > #!/bin/sh
> > PATH=/whatver/you/need
> > while true; do
> > serve -s /path/to/your/service
> > sleep 5
> > done
> > 
> > Then arrange for this script to be executed at boot time, and that's it.
> > No background stuff, no polling from crontab.  Just a simple loop.
> 
> Thanks Greg. I will update with the way you gave.
> where will I setup this script for systemd job? any reference?

Well... see, normally you wouldn't use this script *and* systemd.
This script is something you'd use *instead* of creating a systemd unit.

If you're going to use a shell script to set up the PATH and other
environment variables and chain-load the service, but manage it all with
systemd, then the script would look something like this:

#!/bin/sh
set -a
PATH=/whatever/you/need
SOME_OTHER_VAR=stuff
exec serve -s /path/to/your/service

Even this is still considered less than optimal, but it does simplify
maintenance.  If you need to adjust the service's environment frequently,
you can edit the shell script more easily than you can edit the unit
file.  So, using this hybrid approach isn't the worst thing you could do.

Now, in terms of setting up the unit file -- assuming you want a
system-wide service rather than a --user service, I'd go in one of two
directions, depending on whether you want to run it as yourself, or as
a dedicated user.

If you're going to run it as yourself, albeit in a system-wide unit,
I'd put it in your $HOME/bin/ directory.  That's where it makes sense
to put scripts that you've written that only you use.

If you're going to set up a dedicated user account to run it, then I'd
put the script in /usr/local/bin or /usr/local/sbin.  (But realistically,
the hybrid approach with a systemd unit *and* a script doesn't really
fit with the dedicated user.)

For writing a unit file, there's a basic tutorial at
<https://wiki.debian.org/systemd/Services>.

I don't know how your service works (or Node.js, for that matter),
so I'm not sure if you want a "simple" service, or a "forking" service.
Let's assume "simple" at first.  This is appropriate if the service
is a single process that runs in the foreground and doesn't create
any child processes.

You also need a name.  Let's call it coreyserver.  And let's say you're
going to run it as yourself, and that your username is corey.

Then this unit file might work:

[Unit]
Description=Corey Server
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=5
User=corey
Group=corey
ExecStart=/home/corey/bin/coreyserver

[Install]
WantedBy=multi-user.target

Re: auto restarting in crontab

[coreyh]

On 16/03/2023 09:32, Greg Wooledge wrote:

On Wed, Mar 15, 2023 at 08:00:20PM -0500, Nicholas Geovanis wrote:

On Wed, Mar 15, 2023, 7:56 PM  wrote:
> My script for monitoring Node.js app as follows. I put it in crontab for
> auto-check and restart if failure.


There's so much wrong with that.

If you want to manage a service, the *best* thing you could do would be
to write a systemd unit for it (either a system-wide unit, or a --user
unit, your choice).  Let systemd start it, restart it automatically 
when

it dies if that's what you want, and so on.

If that's more than you want to tackle, and if all you want is
automatic restarting (not the ability to stop it at will), then this
should suffice:

#!/bin/sh
PATH=/whatver/you/need
while true; do
serve -s /path/to/your/service
sleep 5
done

Then arrange for this script to be executed at boot time, and that's 
it.

No background stuff, no polling from crontab.  Just a simple loop.




Thanks Greg. I will update with the way you gave.
where will I setup this script for systemd job? any reference?

regards





>nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &


This will log stdout and stderr in nohup.out in the working directory.
Look for errors there.  I bet it's a PATH issue.

Cron jobs run in a sanitized environment and may not be running with 
the

permissions you have as root on the command line.


I doubt the permissions are different.  Probably just PATH and maybe 
some

other environment variables that the Javascript program expects, but
which are not present in cron's environment.

Re: auto restarting in crontab

[Greg Wooledge]

On Wed, Mar 15, 2023 at 08:00:20PM -0500, Nicholas Geovanis wrote:
> On Wed, Mar 15, 2023, 7:56 PM  wrote:
> > My script for monitoring Node.js app as follows. I put it in crontab for
> > auto-check and restart if failure.

There's so much wrong with that.

If you want to manage a service, the *best* thing you could do would be
to write a systemd unit for it (either a system-wide unit, or a --user
unit, your choice).  Let systemd start it, restart it automatically when
it dies if that's what you want, and so on.

If that's more than you want to tackle, and if all you want is
automatic restarting (not the ability to stop it at will), then this
should suffice:

#!/bin/sh
PATH=/whatver/you/need
while true; do
serve -s /path/to/your/service
sleep 5
done

Then arrange for this script to be executed at boot time, and that's it.
No background stuff, no polling from crontab.  Just a simple loop.

> >nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &

This will log stdout and stderr in nohup.out in the working directory.
Look for errors there.  I bet it's a PATH issue.

> Cron jobs run in a sanitized environment and may not be running with the
> permissions you have as root on the command line.

I doubt the permissions are different.  Probably just PATH and maybe some
other environment variables that the Javascript program expects, but
which are not present in cron's environment.

Re: auto restarting in crontab

[Nicholas Geovanis]

On Wed, Mar 15, 2023, 7:56 PM  wrote:

> Greetings,
>
> My script for monitoring Node.js app as follows. I put it in crontab for
> auto-check and restart if failure.
>
> #!/bin/bash
>
> # scan the port
> nc -z 127.0.0.1 3000
>
> if [ $? -eq 0 ];then
>exit
> else
>killall node
>sleep 1
>nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
> fi
>
>
> I can run the script by manual, but in crontab it won't work. that
> means, when node.js dies, it will not get restarted by this script
> automatically.
>
> Can you give any hints?
>

Cron jobs run in a sanitized environment and may not be running with the
permissions you have as root on the command line.

Thanks
> Corey Hickman
>
>

auto restarting in crontab

[coreyh]

Greetings,

My script for monitoring Node.js app as follows. I put it in crontab for 
auto-check and restart if failure.


#!/bin/bash

# scan the port
nc -z 127.0.0.1 3000

if [ $? -eq 0 ];then
  exit
else
  killall node
  sleep 1
  nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
fi


I can run the script by manual, but in crontab it won't work. that 
means, when node.js dies, it will not get restarted by this script 
automatically.


Can you give any hints?

Thanks
Corey Hickman

Re: root crontab @reboot for loop fails

[Nicolas George]

Timothy M Butterworth (12022-07-16):
> rc.local does not exist in Debian 11. "/etc/rc.local: No such file or
> directory" should it be a file or a directory?

rc.local is for compatibility with legacy admin practices. Somebody
showed in this thread how it is implemented for systemd. In my opinion,
your best course of action is to imitate that for your specific need.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: root crontab @reboot for loop fails

[Greg Wooledge]

On Sat, Jul 16, 2022 at 12:06:38PM -0400, Timothy M Butterworth wrote:
> rc.local does not exist in Debian 11. "/etc/rc.local: No such file or
> directory" should it be a file or a directory?

If you wish to use it, it must be a file, with execute permission, and
with a valid shebang (#!/bin/sh).

Re: root crontab @reboot for loop fails

[Timothy M Butterworth]

On Fri, Jul 15, 2022 at 11:07 PM Greg Wooledge  wrote:

> On Sat, Jul 16, 2022 at 03:49:09AM +0100, Gareth Evans wrote:
> > $ sudo crontab -l
> > [...]
> > @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do
> /usr/sbin/zfs destroy $f;done
> > @reboot /usr/sbin/zfs snap -r rpool@reboot
> >
> >
> > Prepending "/usr/sbin/" to "zfs" doesn't make a difference.
>
> Let me start by saying I don't know a single thing about ZFS.
>
> My first reaction to this thread of yours is, "Well, read the email that
> cron sends you and see what the errors are."
>
> But that's the easy and obvious reaction.  My second reaction goes a
> little bit deeper:
>
> "All your crontab entries run in parallel.  So your first line which
> has zfs in it, and your second line which also has zfs in it, those both
> run at the same time.  Is that OK?"
>
> Since I have no idea what any of those ZFS commands do, I can't tell
> whether it's OK to have that race condition.  I suspect it's not OK,
> but what do I know?
>
> My third reaction goes something like this:
>
> "If you wanted to run a bunch of commands a boot time, without setting
> up systemd units for them, and proper dependencies, why didn't you just
> use /etc/rc.local?"
>

rc.local does not exist in Debian 11. "/etc/rc.local: No such file or
directory" should it be a file or a directory?



> Using a crontab to duplicate the functionality of rc.local seems odd to me.
>
> Anyway, read your errors.  They may tell you what's wrong.  Figure out
> whether your commands are allowed to run in parallel.  If they're not,
> use a *script*, instead of a bunch of parallel commands.  That script
> could be /etc/rc.local, or it could be a separate script that you call
> from rc.local, or even call from crontab if you really insist.
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: root crontab @reboot for loop fails

[Gareth Evans]

> On 16 Jul 2022, at 14:39, Anssi Saari  wrote:
> 
> Tixy  writes:
> 
>> rc.local is still run on the latest Debian stable. You need to make
>> sure it's a proper executable, i.e. starts with a shebang like
>> '#!/bin/sh' and the file has execute permissions.
> 
> Yes and that's because the systemd package contains the rc-local.service
> which just runs /etc/rc.local. With a ConditionFileIsExecutable too
> which I wasn't aware of before.

Thanks all, that was both helpful and informative
Gareth

Re: root crontab @reboot for loop fails

[Anssi Saari]

Tixy  writes:

> rc.local is still run on the latest Debian stable. You need to make
> sure it's a proper executable, i.e. starts with a shebang like
> '#!/bin/sh' and the file has execute permissions.

Yes and that's because the systemd package contains the rc-local.service
which just runs /etc/rc.local. With a ConditionFileIsExecutable too
which I wasn't aware of before.

Re: root crontab @reboot for loop fails

[Greg Wooledge]

On Sat, Jul 16, 2022 at 08:13:56AM +0100, Tixy wrote:
> On Sat, 2022-07-16 at 05:30 +0100, Gareth Evans wrote:
> > I was of the impression (which I think it is fair to say has been created) 
> > that systemd had done away with /etc/rc.local
> 
> rc.local is still run on the latest Debian stable. You need to make
> sure it's a proper executable, i.e. starts with a shebang like
> '#!/bin/sh' and the file has execute permissions.

Correct.  You can also see its systemd unit:

unicorn:~$ systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
 Loaded: loaded (/lib/systemd/system/rc-local.service; static)
Drop-In: /lib/systemd/system/rc-local.service.d
 └─debian.conf
 Active: inactive (dead)
   Docs: man:systemd-rc-local-generator(8)

unicorn:~$ systemctl cat rc-local
# /lib/systemd/system/rc-local.service
[...]
[Unit]
Description=/etc/rc.local Compatibility
Documentation=man:systemd-rc-local-generator(8)
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
[...]

I'm not using one on this particular computer, hence "inactive (dead)".
Note also the Debian changes at the end of the unit file (or in the
separate Drop-In literal file if you aren't using "systemctl cat").

Re: root crontab @reboot for loop fails

[Greg Wooledge]

On Sat, Jul 16, 2022 at 05:35:39AM +0100, Gareth Evans wrote:
> On Sat 16 Jul 2022, at 05:30, Gareth Evans  wrote:
> 
> > Why isn't root's $PATH available to root crontab? ie. including the 
> > link /sbin -> /usr/sbin?
> 
> By which I mean: why can't root crontab do everything sudo can do?

Because they're different programs.

crontab(5):

   Several environment variables are set up automatically by  the  cron(8)
   daemon.  SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
   /etc/passwd  line  of  the   crontab's   owner.PATH   is   set   to
   "/usr/bin:/bin". [...]

Debian's /etc/sudoers file:

Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

So, it depends on whether you're using the default settings, or changing
them.

Re: root crontab @reboot for loop fails

[Tixy]

On Sat, 2022-07-16 at 05:30 +0100, Gareth Evans wrote:
> I was of the impression (which I think it is fair to say has been created) 
> that systemd had done away with /etc/rc.local

rc.local is still run on the latest Debian stable. You need to make
sure it's a proper executable, i.e. starts with a shebang like
'#!/bin/sh' and the file has execute permissions.

-- 
Tixy

Re: root crontab @reboot for loop fails

[Gareth Evans]

On Sat 16 Jul 2022, at 05:30, Gareth Evans  wrote:

> Why isn't root's $PATH available to root crontab? ie. including the 
> link /sbin -> /usr/sbin?

By which I mean: why can't root crontab do everything sudo can do?

Thanks
G

Re: root crontab @reboot for loop fails

[Gareth Evans]

Hi Greg,

On Sat 16 Jul 2022, at 04:07, Greg Wooledge  wrote:

[...]

> "Well, read the email that cron sends you and see what the errors are."

[amongst others]
/bin/sh: 1: zfs: not found

suggests the need for /usr/sbin/zfs

It seems reasonable that /usr/sbin/* should be available to root crontab.  

Why isn't root's $PATH available to root crontab? ie. including the link /sbin 
-> /usr/sbin?

> "All your crontab entries run in parallel. 

OK thanks.  Is this documented?  

$ man crontab

then

/parallel
[ie search for "parallel"]

returns nothing.

> "If you wanted to run a bunch of commands a boot time, without setting
> up systemd units for them, and proper dependencies, why didn't you just
> use /etc/rc.local?"

I was of the impression (which I think it is fair to say has been created) that 
systemd had done away with /etc/rc.local, and crontab @reboot is much simpler 
than systemd units and whatever dependencies there may be.

> Figure out whether your commands are allowed to run in parallel [...]

They are not.

> If they're not, use a *script* [...]

With /usr/bin/zfs, that's working, thank you.

Best wishes,
Gareth

Re: root crontab @reboot for loop fails

[Greg Wooledge]

On Sat, Jul 16, 2022 at 03:49:09AM +0100, Gareth Evans wrote:
> $ sudo crontab -l
> [...]
> @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do 
> /usr/sbin/zfs destroy $f;done
> @reboot /usr/sbin/zfs snap -r rpool@reboot
> 
> 
> Prepending "/usr/sbin/" to "zfs" doesn't make a difference.

Let me start by saying I don't know a single thing about ZFS.

My first reaction to this thread of yours is, "Well, read the email that
cron sends you and see what the errors are."

But that's the easy and obvious reaction.  My second reaction goes a
little bit deeper:

"All your crontab entries run in parallel.  So your first line which
has zfs in it, and your second line which also has zfs in it, those both
run at the same time.  Is that OK?"

Since I have no idea what any of those ZFS commands do, I can't tell
whether it's OK to have that race condition.  I suspect it's not OK,
but what do I know?

My third reaction goes something like this:

"If you wanted to run a bunch of commands a boot time, without setting
up systemd units for them, and proper dependencies, why didn't you just
use /etc/rc.local?"

Using a crontab to duplicate the functionality of rc.local seems odd to me.

Anyway, read your errors.  They may tell you what's wrong.  Figure out
whether your commands are allowed to run in parallel.  If they're not,
use a *script*, instead of a bunch of parallel commands.  That script
could be /etc/rc.local, or it could be a separate script that you call
from rc.local, or even call from crontab if you really insist.

Re: root crontab @reboot for loop fails

[Gareth Evans]

$ sudo crontab -l
[...]
@reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do 
/usr/sbin/zfs destroy $f;done
@reboot /usr/sbin/zfs snap -r rpool@reboot


Prepending "/usr/sbin/" to "zfs" doesn't make a difference.

Thanks,
Gareth

root crontab @reboot for loop fails

[Gareth Evans]

Hello,

$ sudo crontab -l | grep reboot
[...]
[1] @reboot sleep 10; nmcli c up 
[2] @reboot for f in $(zfs list -t snap -o name|grep reboot); do zfs destroy 
$f;done
[3] @reboot zfs snap -r rpool@reboot

[1] succeeds, but [2,3] do not.

Any ideas why would be gratefully received.

Many thanks,
Gareth

Re: MY crontab ain't me!

[tomas]

On Mon, Dec 21, 2020 at 12:26:28PM -0500, Gene Heskett wrote:
> On Monday 21 December 2020 10:53:23 to...@tuxteam.de wrote:
> 
> > On Mon, Dec 21, 2020 at 09:50:37AM -0500, Gene Heskett wrote:
> > > On Monday 21 December 2020 09:18:45 to...@tuxteam.de wrote:
> >
> > [...]
> >
> > > > I feel dirty now.
> > >
> > > So do I, even that bow legged name generates ill feelings. Me and my
> > > printer both need a shower. But its better than nothing, and may
> > > accidentally have what it takes to make it work.
> >
> > Hoping you nail it. And careful when showering that printer.
> > If it's a laser, then there's some HV around inside ;-)
> 
> This ones an ink squirter, but I have a much better color laser that 
> despite my being a CET, Brother will not sell me a new corona wire HV 
> generator board for. One of these days I'll diss it and see if I can fix 
> it, likely a bad, high ESR capacitor.

[...]

I know you have been around high voltages and high frequencies, possibly
higher than many of us, so my comment was a bit tongue-in-cheek ;-P

Cheers
 - t


signature.asc
Description: Digital signature

Re: MY crontab ain't me!

[tomas]

On Mon, Dec 21, 2020 at 10:04:48AM -0600, Nicholas Geovanis wrote:
> On Mon, Dec 21, 2020, 8:19 AM  wrote:
> 
> > On Mon, Dec 21, 2020 at 03:09:32PM +0100, to...@tuxteam.de wrote:
> >
> > [environment variables and things]
> >
> > Wel, the DCOP docs are here [1] (Ah, Doxygen docs. Is there a
> > term for "illiterate programming"?).
> > 
> >
> 
> The Jesus-freak spirit of Knuth rebukes you 😂
> It's a tangled web he weaves, only the lonely survive. But any committed
> Christian with a pipe organ that size in his own home might be salvageable.
> 🙄

Yeah. The term came to me thinking of DEK. Somehow the process is the
inverse of literate programming: you write the code, and the docs
follow -> illiterate programming.

To be fair, the DCOP doc isn't /that/ bad, but having suffered Doxygen
for many a Java project "this function has that-and-that name and takes
this-and-that types of args" hey, the source knows that already! I'm
a bit wary of that. Thus my snark.

Cheers
 - t


signature.asc
Description: Digital signature

Re: MY crontab ain't me!

[Gene Heskett]

On Monday 21 December 2020 10:53:23 to...@tuxteam.de wrote:

> On Mon, Dec 21, 2020 at 09:50:37AM -0500, Gene Heskett wrote:
> > On Monday 21 December 2020 09:18:45 to...@tuxteam.de wrote:
>
> [...]
>
> > > I feel dirty now.
> >
> > So do I, even that bow legged name generates ill feelings. Me and my
> > printer both need a shower. But its better than nothing, and may
> > accidentally have what it takes to make it work.
>
> Hoping you nail it. And careful when showering that printer.
> If it's a laser, then there's some HV around inside ;-)

This ones an ink squirter, but I have a much better color laser that 
despite my being a CET, Brother will not sell me a new corona wire HV 
generator board for. One of these days I'll diss it and see if I can fix 
it, likely a bad, high ESR capacitor.

Its not like this is my first electronics rodeo, by about 75 years. And I 
do know what to do with high voltages, one tv transmitter I maintained 
for 8 years could have crowbarred all of Wayne County Nebraska if a 
filter capacitor shorted. Over 300KWH was its normal singing voice.  Add 
at least another 0 to that when shorted by a klystron full of water 
because a $75 circuit breaker failed and single phased a 15 hp water 
pump.

Because of the cost of that klystron, the guv had to call in a quorum of 
the legislature to write the check for a new one. About $150,000 at the 
time for everything. That also got circuitry installed to stop that from 
ever happening again. Expen$ive lesson but that fix was then installed 
at all the NETV sites that were UHF and subject to that failure mode. 2 
others IIRC.

> Cheers, good luck
>  - t


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: MY crontab ain't me!

[Nicholas Geovanis]

On Mon, Dec 21, 2020, 8:19 AM  wrote:

> On Mon, Dec 21, 2020 at 03:09:32PM +0100, to...@tuxteam.de wrote:
>
> [environment variables and things]
>
> Wel, the DCOP docs are here [1] (Ah, Doxygen docs. Is there a
> term for "illiterate programming"?).
> 
>

The Jesus-freak spirit of Knuth rebukes you 😂
It's a tangled web he weaves, only the lonely survive. But any committed
Christian with a pipe organ that size in his own home might be salvageable.
🙄

>  - t
>

Re: MY crontab ain't me!

[tomas]

On Mon, Dec 21, 2020 at 09:50:37AM -0500, Gene Heskett wrote:
> On Monday 21 December 2020 09:18:45 to...@tuxteam.de wrote:

[...]

> > I feel dirty now.
> 
> So do I, even that bow legged name generates ill feelings. Me and my 
> printer both need a shower. But its better than nothing, and may 
> accidentally have what it takes to make it work.

Hoping you nail it. And careful when showering that printer.
If it's a laser, then there's some HV around inside ;-)

Cheers, good luck
 - t


signature.asc
Description: Digital signature

Re: MY crontab ain't me!

[Gene Heskett]

On Monday 21 December 2020 09:18:45 to...@tuxteam.de wrote:

> On Mon, Dec 21, 2020 at 03:09:32PM +0100, to...@tuxteam.de wrote:
>
> [environment variables and things]
>
> Wel, the DCOP docs are here [1] (Ah, Doxygen docs. Is there a
> term for "illiterate programming"?). Convincing my search engine
> to search that site for "environment variable" yields some hits
> (e.g. [2]) -- it seems a bit more involved that "just" setting
> an env variable (reading a file in your home directory and
> things).
>
> I feel dirty now.

So do I, even that bow legged name generates ill feelings. Me and my 
printer both need a shower. But its better than nothing, and may 
accidentally have what it takes to make it work.

Thanks Tomas
>
> Cheers
>
> [1] https://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/index.html
> [2]
> https://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/index.html#iuc
>
>  - t


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: MY crontab ain't me!

[tomas]

On Mon, Dec 21, 2020 at 03:09:32PM +0100, to...@tuxteam.de wrote:

[environment variables and things]

Wel, the DCOP docs are here [1] (Ah, Doxygen docs. Is there a
term for "illiterate programming"?). Convincing my search engine
to search that site for "environment variable" yields some hits
(e.g. [2]) -- it seems a bit more involved that "just" setting
an env variable (reading a file in your home directory and
things).

I feel dirty now.

Cheers

[1] https://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/index.html
[2] https://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/index.html#iuc

 - t


signature.asc
Description: Digital signature

Re: MY crontab ain't me!

[tomas]

On Mon, Dec 21, 2020 at 08:42:26AM -0500, Gene Heskett wrote:
> I got an email from cron this morning that needs some explaining.
> Here is a dcop connand _I_ can execute, no error
> /opt/trinity/bin/dcop kmail KMailIface resumeBackgroundJobs
> 
> But I put it in MY crontab and get this email
> 
> Cron  /opt/trinity/bin/dcop kmail KMailIface 
> resumeBackgroundJobs
>  From: Cron Daemon 
>  To: g...@coyote.coyote.den
>  
> ERROR: Couldn't attach to DCOP server!
> 
> I have other scripts to aid my incoming email that run as me, and use 
> dcop to get their job done w/o a problem.
> 
> But put the exact same command in MY crontab and its rejected.

This is, as I gather, your "personal" crontab. So the cron job
is running under you UID. Good.

> 2 questions, why?, and why is this email from root?

As to your first question, the most probable cause is that your
cron job hasn't the environment needed to get in touch with
the DCOP server.

One typical mechanism (note that I know zilch about DCOP, and,
to be honest, would like to avoid dirtying my soul with all
the saddening details ;-) is that DCOP listens on some socket.
Typically (again), there is an environment variable (or several)
in your session's environment containing the coordinates of
said socket (or - whatever).

What you can do is (besides reading DCOP's documentation, if
any) issue

  set | grep DCOP

(or some variation on it) to find about likely environment
variable candidates. This, of course, from a shell running
under your DE's environment (a terminal window started from
your GUI will do).

Then set those environment variables in your cron job. The
crontab format itself (cf. man 5 crontab) has provisions to
set environment -- alternatively you can call from there a
script setting the necessary environment (perhaps because
you don't want all your cron entries to have the same
environment).

Possibly DCOP has some utility to "join" a user "session",
dunno.

But this all is a hunch. Some tinkering needed.

I test out such things by letting my cron commands append
debugging stuff to some temporary file. By default, cron
has no logfiles and mails you its complaints, as you
already found out.

As to your second question -- cron runs as root and changes
to the relevant UID when needed (it couldn't were it not
root).


signature.asc
Description: Digital signature

Re: MY crontab ain't me!

[Greg Wooledge]

On Mon, Dec 21, 2020 at 08:42:26AM -0500, Gene Heskett wrote:
> I got an email from cron this morning that needs some explaining.
> Here is a dcop connand _I_ can execute, no error
> /opt/trinity/bin/dcop kmail KMailIface resumeBackgroundJobs
> 
> But I put it in MY crontab and get this email
> 
> Cron  /opt/trinity/bin/dcop kmail KMailIface 
> resumeBackgroundJobs
>  From: Cron Daemon 
>  To: g...@coyote.coyote.den
>  
> ERROR: Couldn't attach to DCOP server!

Each process has an execution environment, which is inherited from its
parent process.

When you log in to a desktop session, either through a Display Manager
or by running startx, you get a whole bunch of environment variables
created for you, like DISPLAY, and XDG_SESSION_ID, and so on.  These
variables are set by some primal process in the session, and are
propagated down to all of the other things that you run, like window
managers, and terminal emulators, and web browsers.

A cron job is started by the cron daemon, which runs with basically
no environment at all.  The cron daemon injects a very small number of
variables into your environment for your jobs, like PATH and HOME, but
not much more than this.

I don't know how "dcop" works, but apparently when you run it from cron,
it doesn't have access to the resources it's expecting.  You'll need
to contact people who know something about dcop, and ask them what it
needs.  It might be as simple as adding some variables to your crontab,
or it might be much harder.

Maybe if you get lucky, someone on this list will know about dcop, and
you won't have to seek topic experts.

MY crontab ain't me!

[Gene Heskett]

I got an email from cron this morning that needs some explaining.
Here is a dcop connand _I_ can execute, no error
/opt/trinity/bin/dcop kmail KMailIface resumeBackgroundJobs

But I put it in MY crontab and get this email

Cron  /opt/trinity/bin/dcop kmail KMailIface 
resumeBackgroundJobs
 From: Cron Daemon 
 To: g...@coyote.coyote.den
 
ERROR: Couldn't attach to DCOP server!

I have other scripts to aid my incoming email that run as me, and use 
dcop to get their job done w/o a problem.

But put the exact same command in MY crontab and its rejected.

2 questions, why?, and why is this email from root?

Thanks for any enlightenment.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Does Debian crontab support the @NumberOfSeconds scheduling syntax?

[Judah Richardson]

Thanks all, I wound up just using @monthly instead.

On Sun, Aug 18, 2019 at 4:56 AM Sven Joachim  wrote:

> On 2019-08-18 08:10 +0200, Sven Hartge wrote:
>
> > Judah Richardson  wrote:
> >
> >> In FreeBSD and derived OSes, you can use @n, where n is a number, to
> >> indicate that a task should be started n seconds after its previous
> >> invocation completed.
> >
> >> I couldn't find anything like that in the Debian crontab
> >> documentation. Is it supported or possible?
> >
> > This is not something Vixie cron in Debian supports.
> >
> > You could achieve something like this with systemd.timers though.
>
> To elaborate on that, systemd.timer(5) mentions the following option:
>
> ,
> | OnUnitInactiveSec= defines a timer relative to when the unit the timer
> | is activating was last deactivated.
> `
>
> Cheers.
>Sven
>
>

Re: Does Debian crontab support the @NumberOfSeconds scheduling syntax?

[Sven Joachim]

On 2019-08-18 08:10 +0200, Sven Hartge wrote:

> Judah Richardson  wrote:
>
>> In FreeBSD and derived OSes, you can use @n, where n is a number, to
>> indicate that a task should be started n seconds after its previous
>> invocation completed.
>
>> I couldn't find anything like that in the Debian crontab
>> documentation. Is it supported or possible?
>
> This is not something Vixie cron in Debian supports.
>
> You could achieve something like this with systemd.timers though.

To elaborate on that, systemd.timer(5) mentions the following option:

,
| OnUnitInactiveSec= defines a timer relative to when the unit the timer
| is activating was last deactivated.
`

Cheers.
   Sven

Re: Does Debian crontab support the @NumberOfSeconds scheduling syntax?

[Sven Hartge]

Judah Richardson  wrote:

> In FreeBSD and derived OSes, you can use @n, where n is a number, to
> indicate that a task should be started n seconds after its previous
> invocation completed.

> I couldn't find anything like that in the Debian crontab
> documentation. Is it supported or possible?

This is not something Vixie cron in Debian supports.

You could achieve something like this with systemd.timers though.

Grüße,
S!

-- 
Sigmentation fault. Core dumped.

Does Debian crontab support the @NumberOfSeconds scheduling syntax?

[Judah Richardson]

In FreeBSD and derived OSes, you can use @n, where n is a number, to
indicate that a task should be started n seconds after its previous
invocation completed.

I couldn't find anything like that in the Debian crontab documentation. Is
it supported or possible?

Re: nother problem I can't access my crontab, no perms

[Étienne Mollier]

On 5/20/19 8:40 PM, Gene Heskett wrote:
>> I would tend to believe that execution of "crontab" related
>> commands will benefit from the proper UIDs when operating.  On
>> my machine, at the same working directory, I have:
>>
>>  $ sudo ls -lR
>>  .:
>>  total 0
>>  drwx-wx--T 2 root crontab 21 Feb 28 22:49 crontabs
>>
>>  ./crontabs:
>>  total 4
>>  -rw--- 1 user crontab 381 Feb 28 22:49 user
>>
>> It would seem that your restore attempt conserved UIDs, but
>> crontab's former UID has become systemd-timesyncd one.  Perhaps
>> a well placed `chgrp -R crontab crontabs/` will do?

Whoopsie, for the sake of precision, I mostly meant GID (Group
Identifier) instead of UID (User Identifier).

> Absolutely spot on,  Étienne Mollier, thank you very much.  Now cron has 
> about 2 weeks work to catch up on. :)

Glad to read that  :)
-- 
Étienne Mollier 

Re: nother problem I can't access my crontab, no perms

[Gene Heskett]

On Monday 20 May 2019 02:21:20 pm Étienne Mollier wrote:

> Good Day Gene,
>
> On coyote, /var/spool/cron contained:
> > drwx-wx--T  2 root   systemd-timesync 4096 Mar 31 09:15 crontabs
>
>  ^^^
> You can't go through this "crontab" directory if you are not
> root, or a member of the group systemd-timesync.  That includes
> that you can't read any file below, even if it is attributed to
> you.
>
> I would tend to believe that execution of "crontab" related
> commands will benefit from the proper UIDs when operating.  On
> my machine, at the same working directory, I have:
>
>   $ sudo ls -lR
>   .:
>   total 0
>   drwx-wx--T 2 root crontab 21 Feb 28 22:49 crontabs
>
>   ./crontabs:
>   total 4
>   -rw--- 1 user crontab 381 Feb 28 22:49 user
>
> It would seem that your restore attempt conserved UIDs, but
> crontab's former UID has become systemd-timesyncd one.  Perhaps
> a well placed `chgrp -R crontab crontabs/` will do?
>
> Kind Regards,

Absolutely spot on,  Étienne Mollier, thank you very much.  Now cron has 
about 2 weeks work to catch up on. :)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: nother problem I can't access my crontab, no perms

[Étienne Mollier]

Good Day Gene,

On coyote, /var/spool/cron contained:
> drwx-wx--T  2 root   systemd-timesync 4096 Mar 31 09:15 crontabs
 ^^^
You can't go through this "crontab" directory if you are not
root, or a member of the group systemd-timesync.  That includes
that you can't read any file below, even if it is attributed to
you.

I would tend to believe that execution of "crontab" related
commands will benefit from the proper UIDs when operating.  On
my machine, at the same working directory, I have:

$ sudo ls -lR
.:
total 0
drwx-wx--T 2 root crontab 21 Feb 28 22:49 crontabs

./crontabs:
total 4
-rw--- 1 user crontab 381 Feb 28 22:49 user

It would seem that your restore attempt conserved UIDs, but
crontab's former UID has become systemd-timesyncd one.  Perhaps
a well placed `chgrp -R crontab crontabs/` will do?

Kind Regards,
-- 
Étienne Mollier