Cron job error?

[KenGordon]

What is wrong with this cron job?

#/bin/sh
# Automated Lynis Scan Script

#Define log and report paths
LOGFILE="/var/log/lynis-cron.log"
REPORTFILE="/var/log/lynis-report.dat"
/usr/local/bin/lynis "audit system --/usr/local/bin/lynis_cron.sh --quick > $LOGFILE 2>&1"

# Optional: Send an email alert if warnings are found in log
if grep -q "Warning:" $LOGFILE; then mail -s "Lynis Security Warning on $KensOffice" root > LOGFILE
fi[

I keep getting a "bad minute" error in line 6, but I am suspecting it means line 7. In any case, I cannot figure out what I did wrong.

Ken Gordon

 

[bakul]

You need to specify cron jobs in crontab(5) format. See /etc/crontab for an example.

 

[Maturin]

if grep -q "Warning:" $LOGFILE; then mail -s "Lynis Security Waring on $KensOffice" root > LOGFILE
fi[

I'm a bit confused about that line, since the syntax shall be if [ condition ] ; then expressions fi,
and not if condition; then expressions fi[, right?

 

[KenGordon]

So, "conditions" should be within square brackets?

Like this: if [grep -q "Warning" $LOGFILE]; then mail (etc) .?

Ken Gordon

 

[mer]

I'm a bit confused about that line, since the syntax shall be if [ condition ] ; then expressions fi,
and not if condition; then expressions fi[, right?

It looks more bash syntax than sh.

 

[bakul]

I suspect we still have a failure to communicate. The "bad minute" is an error message from cron, when it is reading a crontab and expects a time specification (which starts with a minute spec -- a number). Your script above is a shell script. You need to create a proper crontab entry with the "crontab" command.

 

[bakul]

I'm a bit confused about that line, since the syntax shall be if [ condition ] ; then expressions fi,

No, that is fine. "if <foo>" looks at the status of the program foo. And "/bin/[" is hard-linked to "/bin/test" which is why the "nicer" syntax works.

 

[Kai Burghardt]

Dude. Read the handbook.​

--- lyniscan~   2026-06-06 00:24:38.797781607 +0000
+++ lyniscan    2026-06-06 00:24:38.797781607 +0000
@@ -1,12 +1,11 @@
-
-#/bin/sh
+#!/bin/sh -eu
 # Automated Lynis Scan Script

 #Define log and report paths
 LOGFILE="/var/log/lynis-cron.log"
 REPORTFILE="/var/log/lynis-report.dat"
-/usr/local/bin/lynis "audit system --/usr/local/bin/lynis_cron.sh --quick > $LOGFILE 2>&1"
-
+/usr/local/bin/lynis audit system --quiet --logfile $LOGFILE --report-file $REPORTFILE
+STATUS=$?
 # Optional: Send an email alert if warnings are found in log
-if grep -q "Warning:" $LOGFILE; then mail -s "Lynis Security Warning on $KensOffice" root > LOGFILE
-fi[
+grep -q "Warning:" $LOGFILE && mail -s "Lynis Security Warning on $KensOffice" root < $LOGFILE
+# We are not really interested in the exit status of grep or mail.
+exit $STATUS

So, "conditions" should be within square brackets?

No, it’s a list. The exit status of the last command in the list matters. As bakul pointed out, /bin/[ is a program (although frequently [ is a shell built‑in, cmp. type [).​

 

[KenGordon]

Well, in addtion to the error Maturin found, I found several others which I had to correct.

I tested the cron job several times before I got them all.

Now we will see if I edited the crontab correctly. I did crontab -e and added one line.

Now we will see.

Ken Gordon

 

[KenGordon]

I suspect we still have a failure to communicate. The "bad minute" is an error message from cron, when it is reading a crontab and expects a time specification (which starts with a minute spec -- a number). Your script above is a shell script. You need to create a proper crontab entry with the "crontab" command.

Yes. I (finally) did that. Thanks.

Ken Gordon

 

[KenGordon]

Dude. Read the handbook.​

--- lyniscan~   2026-06-06 00:24:38.797781607 +0000
+++ lyniscan    2026-06-06 00:24:38.797781607 +0000
@@ -1,12 +1,11 @@
-
-#/bin/sh
+#!/bin/sh -eu
 # Automated Lynis Scan Script

 #Define log and report paths
 LOGFILE="/var/log/lynis-cron.log"
 REPORTFILE="/var/log/lynis-report.dat"
-/usr/local/bin/lynis "audit system --/usr/local/bin/lynis_cron.sh --quick > $LOGFILE 2>&1"
-
+/usr/local/bin/lynis audit system --quiet --logfile $LOGFILE --report-file $REPORTFILE
+STATUS=$?
 # Optional: Send an email alert if warnings are found in log
-if grep -q "Warning:" $LOGFILE; then mail -s "Lynis Security Warning on $KensOffice" root > LOGFILE
-fi[
+grep -q "Warning:" $LOGFILE && mail -s "Lynis Security Warning on $KensOffice" root < $LOGFILE
+# We are not really interested in the exit status of grep or mail.
+exit $STATUS

No, it’s a list. The exit status of the last command in the list matters. As bakul pointed out, /bin/[ is a program (although frequently [ is a shell built‑in, cmp. type [).​

Yes. That is what I tell those I have to walk through their use of new radio equipment: RTFM. I have printed all 42 pages of that. Thanks.

Ken Gordon

 

[Maturin]

So, "conditions" should be within square brackets?

Yes. Edit: Can, but don't must.
But watch out to have a space " " between brackets and the first and last sign. It's [ x ] not [x] (This also get's me some times again. )
see The Shell Scripting Tutorial - Test

Also watch out for commenting. I find that the most tricky part when starting on shell scripting, to get that right. Especially, when variables and escape characters are involved.

 

[Maturin]

Now we will see if I edited the crontab correctly. I did crontab -e and added one line.

Better always debug a script first, and ensure it does its job correctly before you let cron take over, since depending on the schedule you may not only need to wait for too long until it's executed, but depending on what it does and which bug(s) it may still contain it can produce a lot of garbage you need to clean afterwards, or even can do damage.
The advantage of automation is, the computer does jobs quickly for you, so you don't need to care anymore.
The disadvantage of automation is, you need to care more carefully before you start any automation. If the job is to produce junk (because of a bug) you get pretty fast pretty large heaps of junk.
It's kinda like copy stuff: It's pretty comfy to produce one thing, and then copy it many times instead of producing it for every occasion. But once your template is buggy, so are all the copies.

You may run the script for testing purposes within a test environment, like with modified variables (copy each definition line, and comment out the one you don't need at the moment was one way to do it), like sending the log's output to some /tmp/garbage/test.log or replace some time consuming executions or critical writing commands by simple echos.
Plus adding temporary exits can help a lot to run a script only to that point for testing purposes, so not always the whole shebang completely if you wanna just see if one variable is used correctly. (Don't forget to remove/comment them afterwards. Otherwise you may wonder why the shit does not do its full job. )
Also you can get a lot of useful information while debugging of what your script really does if you start it with the -x option: sh -x mystillnotreleasedscript.sh

 

[Maturin]

It looks more bash syntax than sh.

It does? I learned that's sh. bash does also provide such things as [[ ]] or something like that.
Anyway almost all my scripts are sh and all my ifs look all that way, and work:

#!/bin/sh

#[...]

if [ ! -e "${WDIR}" ]
        then
        mkdir ${WDIR}
fi

#[...]

exit 0

 

[mer]

Specifically the if:
if grep -q "Warning:" $LOGFILE

I've only ever seen that in people specifically using bash.
Now it may also be legal sh syntax.
And don't forget the spaces around the "[" and "]"

 

[bakul]

perfectly legal!

 

[Maturin]

So, "conditions" should be within square brackets?

No. You can do it, but you don't have to.

Now it may also be legal sh syntax.

perfectly legal!

It is.
I just checked some sources on that topic.
You can use brackets, and I learned to do so, and I do so, because to me it also increases the understandability, but you don't have to.
If you do so, as mer and me also already said, you need to place spaces between the brackets and sorrounding signs, because a bracket directly attached to another sign has another meaning.

As I say: You never stop learning.
Thanks guys!