Where do I go to check the logs that things are running?

I don't think my cron jobs for nodelist and infopack creation are running as intended.

I just added this last line to test and nothing seemed to happen either.
I had previously used numbers for dow so 4 and 5 for thu and fri respectively

# m h dom mon dow command
0 0 * * * /hub/bats/logbackup.sh
15 2 * * thu /hub/bats/make-region57.sh
15 2 * * fri /hub/bats/fsxnode.sh
20 2 * * fri /hub/bats/fsxinfo.sh
30 14 * * sun /hub/bats/fsxinfo.sh

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 07 Mar 2021 at 02:34p, Avon pondered and said...

Where do I go to check the logs that things are running?
30 14 * * sun /hub/bats/fsxinfo.sh

I found this in syslog

Mar 7 14:30:01 orac CRON[22726]: (avon) CMD (/hub/bats/fsxinfo.sh)
Mar 7 14:30:01 orac CRON[22727]: (root) CMD ([ -x /etc/init.d/anacron ] &&
if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mar 7 14:30:07 orac CRON[22725]: (CRON) info (No MTA installed, discarding output)


Looks like it ran... I'll keep digging it could be my script that's duff
still.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Where do I go to check the logs that things are running?

Cron runs on faith!

I don't think my cron jobs for nodelist and infopack creation are running as intended.

I just added this last line to test and nothing seemed to happen either.
I had previously used numbers for dow so 4 and 5 for thu and fri respectively

# m h dom mon dow command
0 0 * * * /hub/bats/logbackup.sh
15 2 * * thu /hub/bats/make-region57.sh
15 2 * * fri /hub/bats/fsxnode.sh
20 2 * * fri /hub/bats/fsxinfo.sh
30 14 * * sun /hub/bats/fsxinfo.sh

Keep in mind that the environment cron runs in is almost bald. There is no path in the environment unless you put it there in the script.

Looks like you need zip for those so use the full path /usr/bin/zip, or add a path in those scripts before you get started.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.2)

On 06 Mar 2021 at 06:09p, Al pondered and said...

Keep in mind that the environment cron runs in is almost bald. There is
no path in the environment unless you put it there in the script.

Looks like you need zip for those so use the full path /usr/bin/zip, or add a path in those scripts before you get started.

I guess it could be a pathing issue in the script.

I note when it runs the script I see

Mar 7 15:21:01 orac CRON[25958]: (avon) CMD (/hub/bats/fsxinfo.sh)
Mar 7 15:21:01 orac CRON[25957]: (CRON) info (No MTA installed, discarding output)

Is that latter line an issue that could cause the script not to run?

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Looks like you need zip for those so use the full path /usr/bin/zip, or
add a path in those scripts before you get started.

I guess it could be a pathing issue in the script.

If the commands in your script need a path I'd add a line like this to the beginning of the script to source a file with your path.

. /etc/profile <- or whereever your path is set, works with slackware.
. /home/avon/.bash_profile <- Works on debian?

I note when it runs the script I see

Mar 7 15:21:01 orac CRON[25958]: (avon) CMD (/hub/bats/fsxinfo.sh)
Mar 7 15:21:01 orac CRON[25957]: (CRON) info (No MTA installed, discarding output)

Is that latter line an issue that could cause the script not to run?

If your crontab produces errors they will be emailed to you. You don't have an MTA installed so they are discarded. That's harmless but you will not see those
emails.

You could install an MTA but if you don't need it I wouldn't bother. When I ran debian I ran exim4 as my MTA.

You can also redirect the output to /dev/nul in your script so cron will not attempt to send email.

0 0 * * * touch /usr/local/fido/outbound/00e501aa.clo > /dev/null 2>&1

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.2)

On 06 Mar 2021 at 06:41p, Al pondered and said...

If the commands in your script need a path I'd add a line like this to
the beginning of the script to source a file with your path.

. /etc/profile <- or whereever your path is set, works with slackware.
. /home/avon/.bash_profile <- Works on debian?

The issue is a path one, I had not set a PATH statement so added

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/avon/ba ts

This at least got the first line of my script running when started by CRON so that's progress.

Can't see a bash_profile in my home dir, did see a /etc/profile file... but
if the PATH I set above works will that do?

Fingers crossed.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Cron
By: Avon to Al on Sun Mar 07 2021 03:22 pm

I note when it runs the script I see
Mar 7 15:21:01 orac CRON[25958]: (avon) CMD (/hub/bats/fsxinfo.sh)
Mar 7 15:21:01 orac CRON[25957]: (CRON) info (No MTA installed, discarding output)
Is that latter line an issue that could cause the script not to run?

Not necessarily.

Cron can be configured (and it is normally the default), that *any* output during the run (where it completes successfully or not) is emailed to the user that runs the cron. (The user for system crons is normally root unless overrride by a variable.)

...δεσ∩

... When Chuck Norris breaks wind, the wind stays broken.
--- SBBSecho 3.12-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 07 Mar 2021 at 01:53p, deon pondered and said...

Is that latter line an issue that could cause the script not to run?

Not necessarily.

Thanks for the info.

I feel I am playing whack a mole trying to get lines in my script to run.

zip seemed to run but scp did not what is the best way to ensure these
programs like htick, scp, etc. run when called by cron?

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/avon/b
ts

This at least got the first line of my script running when started by CRON so that's progress.

Yes, that works too.

Can't see a bash_profile in my home dir, did see a /etc/profile file... but if the PATH I set above works will that do?

It is a dot file. .bash_profile. Dot files and directories are unseen normally. A command like ls -la .ba* may turn it up. I think that is your bash initialization file.

There may also be an /etc/bash_profile (no dot) in use there but I am unsure how debian does it.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.2)

On 06 Mar 2021 at 06:41p, Al pondered and said...

Looks like you need zip for those so use the full path /usr/bin/zip, or >> add a path in those scripts before you get started.

I guess it could be a pathing issue in the script.

If the commands in your script need a path I'd add a line like this to
the beginning of the script to source a file with your path.

. /etc/profile <- or whereever your path is set, works with slackware.

What is the syntax to use?

PATH=/etc/profile

Would that be enough to cover the assorted tools I am trying to run from my scripts?

Getting a nodelist and infopack out with Windows was never this hard :(

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I feel I am playing whack a mole trying to get lines in my script to run.

That's a cron thing. Cron has a very limited environment by default. Either use full paths or add the needed environment to scripts being run from cron.

zip seemed to run but scp did not what is the best way to ensure these programs like htick, scp, etc. run when called by cron?

Use a full path to scp. On my slackware box it is /usr/bin/scp.

When I run hpt from cron I start it with /usr/local/bin/hpt. hpt doesn't need an environment because it has the full path to zip and unzip in it's config.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.2)

On 06 Mar 2021 at 07:13p, Al pondered and said...

That's a cron thing. Cron has a very limited environment by default. Either use full paths or add the needed environment to scripts being run from cron.

zip seemed to run but scp did not what is the best way to ensure these programs like htick, scp, etc. run when called by cron?

Use a full path to scp. On my slackware box it is /usr/bin/scp.

When I run hpt from cron I start it with /usr/local/bin/hpt. hpt doesn't need an environment because it has the full path to zip and unzip in
it's config.

I think I've managed to get the infopack script to finally run as intended
but ended up adding more stuff to the scripts PATH statement.

That said I think perhaps the way to go would be to explicitly state full
paths to the executable files... what a total phaff :)

Thanks for your help. I'm going to take a break and do some dinner before I
try to tackle the nodelist script

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

. /etc/profile <- or whereever your path is set, works with slackware.

What is the syntax to use?

PATH=/etc/profile

That will not work.

PATH=/usr/bin <- will work for most things.

To source a file the command is..

. /etc/profile

I still think this will work better for you..

. /home/avon/.bash_profile

or maybe

. /etc/bash_profile

Would that be enough to cover the assorted tools I am trying to run from my scripts?

Yes, if the file you source contains the environment, alias's and commands you want sourced.

Getting a nodelist and infopack out with Windows was never this hard :(

Yes, it's the lack of environment provided to cron. Cron's environment is very slim. If your scripts or commands running from cron need an environment you need to set them in your scripts.

Cron was designed to run that way, for some reason.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.2)

I think I've managed to get the infopack script to finally run as intended but ended up adding more stuff to the scripts PATH statement.

Yes, it just arrived here a short time ago.

That said I think perhaps the way to go would be to explicitly state full paths to the executable files... what a total phaff :)

Yes, or source a file that contains your needed environment. Here's a script I use to start binkd and sbbs from cron, it sources /etc/profile but
/etc/bash_profile may work better for you, or ~/.bash_profile.

#!/bin/sh
#
# Script to start binkd and sbbs at boot time.
#
. /etc/profile
/usr/local/sbin/binkd -DC /usr/local/etc/binkd.conf
cd /sbbs
exec/sbbs

Thanks for your help. I'm going to take a break and do some dinner before I try to tackle the nodelist script

Good stuff.. enjoy your dinner.. :)

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.2)

Re: Re: Cron
By: Avon to deon on Sun Mar 07 2021 04:04 pm

zip seemed to run but scp did not what is the best way to ensure these programs like htick, scp, etc. run when called by cron?

...δεσ∩
--- SBBSecho 3.12-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: Re: Cron
By: Avon to deon on Sun Mar 07 2021 04:04 pm

zip seemed to run but scp did not what is the best way to ensure these programs like htick, scp, etc. run when called by cron?

So its been covered - a cron execution environment is pretty much bare.

The most missing variable is your $PATH, which can be set via the system paths (the . /etc/profile, etc) or you can set it explicitely with

export PATH=/patha:/pathb...

If any applications that your cron script is running and dependant on an "environment" you will also need to source or set the appropriate variables.

Also keep in mind, that a variable is only visibile in the current environment (not children of an executed process), unless the variable is "exported" (with export VARIABLE=...)
For portability, I normally set a path to what I need for a script - since location of files and apps could be different depending on which distro of Linux you are using, or who built the application package. (eg: sometimes /usr/bin, sometimes /bin, sometimes /usr/local/bin).

...δεσ∩

... Ending sentences with prepositions is something up with which I will not put.
--- SBBSecho 3.12-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 07 Mar 2021 at 03:23p, deon pondered and said...

Also keep in mind, that a variable is only visibile in the current environment (not children of an executed process), unless the variable
is "exported" (with export VARIABLE=...)

export PATH=/patha:/pathb...

Thanks for the info :) The only thing I can see now is that I should tweak my 'PATH=' statement to 'export PATH=' to avoid the pitfall you mention.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Am 07.03.21 schrieb Avon@21:1/101 in FSX_NET:

Hallo Avon,

Mar 7 15:21:01 orac CRON[25958]: (avon) CMD (/hub/bats/fsxinfo.sh)
Mar 7 15:21:01 orac CRON[25957]: (CRON) info (No MTA installed, discarding output)

Is that latter line an issue that could cause the script not to run?

Just some things as suggestions to your problem:

The "No MTA installed" line indicates that cron wants to send a mail to
you with the output of your script. This mail could tell you the problem,
as it would contain the error messages.

I've installed "nullmailer" on my BBS. This is a bare-bones MTA which
sends out all mails generated on the system to a specific e-mail-address.
It is a Debian package. In /etc/nullmailer/adminaddr, I wrote my e-mail address, and in /etc/nullmailer/remotes, I wrote my mailserver.
If this system is not used for any other SMTP mail stuff, this should work just fine.

As for the cron PATH problem:
In my /etc/crontab (on a Devuan/Debian system), there are two lines at the beginning:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

So I guess, that all the scripts called from /etc/crontab will get these environment variables and thus will get the PATH from here.
You could try, if this works with your cron.

If not, I would suggest to add the PATH line from above to the start of
your scripts or to explicitly write the full path of the programs in the scripts.

Sourcing /etc/profile should also work but it would include other stuff
that might not be needed. And sourcing a bash_profile from the home
directory of some user would work but I would not recommend it as it would mish-mash stuff from users and the system, which is not a clean solution.

I hope that helps you a little.

Regards,
Anna

--- OpenXP 5.0.49
* Origin: Imzadi Box Point (21:3/127.1)

Hello Avon!

On 07 Mar 2021, Avon said the following...

Mar 7 15:21:01 orac CRON[25957]: (CRON) info (No MTA installed, discarding output)

Is that latter line an issue that could cause the script not to run?

No, I think it simply means that there is no software which can e-mail the output of the cron runs.

Perhaps it needs such software to be able to even store the output in a local mailbox (/var/spool/mail/<username>), which I thought is what would happen if no username-to-e-mail mapping is in /etc/aliases for the user in question...

You might wish to install "exim4-daemon-light" to enable basic e-mail functionality. And then edit /etc/aliases to create a username-to-e-mail mapping for the user you execute the cron job as. And also edit /etc/email-addresses to create a similar mapping there, so that e-mails will get a correct From: line.

Best regards
Zip

--- Mystic BBS v1.12 A47 2021/02/12 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

start Mar 7 14:30:07 orac CRON[22725]: (CRON) info (No MTA installed, discarding output)
Looks like it ran... I'll keep digging it could be my script that's duff still.

Cron should normally mail the user the standard output and the standard
error. But that requires a Mail Transfer Agent (MTA) like sendmail
preinstalled ... this is normally done by the default installation of most systems.

On debian for example the MTA called EXIM is installed and any cron jobs (including 'at' commands) are mailed to the user.You will of course need mail(1) from mailutils or bsd-mailx in order to view which I don't think
debian installs by default.

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: Tribe BBS (21:1/177)

Re: Re: Cron
By: acn to Avon on Sun Mar 07 2021 12:55 pm

Sourcing /etc/profile should also work but it would include other stuff that might not be needed. And sourcing a bash_profile from the home directory of some user would work but I would not recommend it as it would mish-mash stuff from users and the system, which is not a clean solution.

Sourcing your own .bash_profile (if you have one, I don't) will result in cron having the usual user environment, if that is what you want.

Ttyl :-),
Al

... This message has been UNIXized for your protection.
--- SBBSecho 3.13-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

On a Pi cron lives in /usr/sbin/cron it has places to check hourly, monthly,,, in /etc/cron.hourly, /etc/cron.monthly, /etc/cron.weekly, /etc/cron.daily,
and the daemon at /etc/cron.d. You can also do man cron and you can find it
via whereis cron or whereis crontab. I take it you edit via crontab -e,

--- Mystic BBS v1.12 A47 2021/02/12 (Raspberry Pi/32)
* Origin: Mystic Pi BBS bcw142.zapto.org (21:1/145)

Sourcing /etc/profile should also work but it would include other stu that might not be needed. And sourcing a bash_profile from the home

Sourcing your own .bash_profile (if you have one, I don't) will result
in cron having the usual user environment, if that is what you want.

Ahh the old question .bashrc or .bash_profile (but not quite)

OUTSIDE OF CRON ...
.bash_profile is used for login shells. .bashrc is used for shells that are both interactive and non-login

Cron should run in a non-login shell but it is also non-interactive and therefore bash ignores both of these startup files

The bash(1) manpage puts it
/etc/profile system wide execution for login shells
~/.bash_profile personal initialization for login shells
(initialized once per terminal)
~/.bashrc individual PER interactive shell
(initialized on every sub shell as well)

INSIDE CRON ...

Cron ignores ALL startup scripts. Period. So adding stuff in the normal places won't work.

The normal recommendations are to

(1) rather than put a command on the command line of the crontab entry but
put a script and ensure that the script declares exactly what it needs to run correctly.
This has the advantage over (2) in that if you mess around with your .bash_profile or .bashrc and you are sourcing that then your batch jobs are
not messed up (which are usually much more important).

(2) place the settings in .bash_profile or .bashrc and then source them. This ends up outputting potentially a lot into the cron logs that don't need to be there. In addition the more commands and settings you have in your startup scripts the more chance of messing up what should be a simple script.

(3) put the settings in a seperate file and source that. But then why bother just place it in the script itself.

Most experienced system admins would opt for (1) with explicit exports for every variable needed. At least that way the script is self contained and you are not contaminating your startup files with stuff that is only used in a
one off script.

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: Tribe BBS (21:1/177)

Cron runs on faith!

That and perserverance or frustration.

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: Tribe BBS (21:1/177)

Re: Re: Cron
By: hal to Al on Mon Mar 08 2021 03:14 pm

Ahh the old question .bashrc or .bash_profile (but not quite)

Yep, I don't use those on my slackware setup, just /etc/profile. The /etc/profile does other things too like sourcing /etc/profile.d/local.sh and others.

Sourcing that file gives me the same environment that I always have once I am logged in.

OUTSIDE OF CRON ...
.bash_profile is used for login shells. .bashrc is used for shells that are both interactive and non-login

This is the missing detail. When you run commands from cron there is very little in the environment and folks don't expect that.

Ttyl :-),
Al

... for it is the doom of men that they forget.
--- SBBSecho 3.13-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Re: Re: Cron
By: hal to Al on Mon Mar 08 2021 03:15 pm

Cron runs on faith!

That and perserverance or frustration.

Yes, when I first hit this issue I didn't know about the environment of cron being different than a users environment.

Know that I know that there is no frustration but it took a while for me to figure that one out. ;)

Ttyl :-),
Al

... Diplomacy is the art of letting someone else have your way.
--- SBBSecho 3.13-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)