i have a script that is need cron to run the problem the cron dont run what i make wrong
cronjob="PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
0 1 * * * root /usr/bin/mylicense >/dev/null 2>&1"
sudo echo "0 1 * * * /usr/bin/mylicense" > /etc/cron.d/mylicense
All three of those commands have a problem. On a modern Linux/Unix, the crottab editor would not even create a file containing them. In what context are you issuing them ?
First line: Assigning to cronjob does nothing useful, and the quotes are unpaired. You need to edit the assignment into your cron job file using the editor launched by crontab -e and the value only should be quoted:
PATH = "/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin"
Second line: This is also badly quoted. It also would only be valid in a root crontab, not a user-level one. So which user does this crontab belong to ?
Third line: This looks like a terminal command that writes a cron job line into the job hierarchy. As it recreates the whole file, it seems to have no connection to the other two lines. If (as generally recommended) you use absolute pathnames, PATH will not be used or needed.
Perhaps you could add some details on distro and version, machine, and purpose. This code seems to be assembled from more than one source.
Also note that there are very specific rules about files and directories under /etc/cron.d as regards naming, ownership, environment and permissions (see man -s 8 cron for the full story).
As far as I remember, assigning variables in crontab also does not allow any spaces around =.
It's not a shell, though, although it might indeed be better to be consistent. I checked the man page before posting, and the spaces are optional (and so are the quotes, unless you specifically want leading or trailing spaces).
More importantly though, assignments are not subject to shell-like substitutions.
Welcome!
Your post is hard to read. Please form separate sentences!
Your first two code lines set a variable. That you can query with
echo "$cronjob"
It has got a user column "root" so is suitable for a Linux system cron file in /etc/cron.d/
You need root right to write to /etc/cron.d/
A sudo ends after one command, a ">" redirection is outside the sudo context; the following is denied:
sudo echo "$cronjob" > /etc/cron.d/mylicense
But the following runs a command that directly writes to the given file:
echo "$cronjob" | sudo tee /etc/cron.d/mylicense > /dev/null
Opposed to the system cron file, a traditional user crontab does not have a user column, because it runs as the user who owns it.
The user creates it interactively with
crontab -e
or by commands like
crontabentry="0 1 * * * /usr/bin/mylicense"
(crontab -l; echo "$crontabentry") | crontab -
where crontab -l lists the current crontab (can give an error if yet empty), then the new entry is printed after it, then the result is written to a new crontab.
[quote="MadeInGermany, post:5, topic:393827"]this is my full script
echo "$cronjob"
[/quote]
#!/bin/bash
echo ""
echo -e '\E[37;32m''\033[1m*********************************************************************\033[0m'
echo -e '\E[37;32m''\033[1m License Installer \033[0m'
echo -e '\E[37;32m''\033[1m*********************************************************************\033[0m'
echo ""
echo ""
cuser=$(whoami)
if [ $cuser != "root" ]; then
echo ""
echo "ERROR: Please run installer as root.";
echo "";
exit 1;
echo ""
fi
wget --timeout=15 --tries=5 -O /usr/bin/mylicense --no-check-certificate https://xxx.com/mylicense>/dev/null 2>&1
chmod +x /usr/bin/mylicense
/usr/bin/mylicense
cd
rm -rf installer
cronjob="PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
0 1 * * * root /usr/bin/mylicense >/dev/null 2>&1"
sudo echo "0 1 * * * root /usr/bin/mylicense" > /etc/cron.d/mylicense
echo "[+] Done!! Activation done !!"
But the cron dont run
Thank you for providing this information. So, to be clear then, after you manually run this script as root on the server, you find that the cron job the script creates does not run at 01:00 local time on the server, is that correct ?
If that is the case, then can you check the following, please:
/etc/cron.d/mylicense exist, and does it have the correct contents ?/usr/bin/mylicense exist and have the correct permissions and ownerships ?/usr/bin/mylicense from working correctly when run via cron./usr/bin/mylicense yourself, does it actually work, or does it produce some unexpected result or error on this particular server ? It may be that everything is absolutely fine with your cron job, and that the issue is with the functionality of the downloaded binary itself.Hope this helps !
This checks for the current user is "root"
Maybe a safer test is to test for write permission:
if [ -w / ]; then
If you are root then do not use sudo !
Why are you setting the cronjob variable?
I think you want
cronjob="PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
0 1 * * * root /usr/bin/mylicense >/dev/null 2>&1"
echo "$cronjob" > /etc/cron.d/mylicense
Ensure your cron service is running:
service crond status
On some Linux distros it is
service cron status
The service command is on most Linux distros a front end command that runs the native command.
It really helps if you tell us your distro.
Commands:
lsb_release -a
cat /etc/*release
uname -a
Is this line accurately posted? The My bad: it works, but it disguises an important shell operator.> is only effective if it is preceded by whitespace. This command tries to get a file literally called https://xxx.com/mylicense>/dev/null.
shellcheck throws four errors on this script, including @MadeInGermany yesterday about redirections on sudo commands: the redirection is done by the shell before the sudo command is run, and therefore the user permissions apply at that point.
You should check whether the wget fails.
You should check if the cd fails. root is very powerful -- you really need to avoid unexpected issues and any knock-on effects.
Sorry no, the shell always detects the unquoted > as a redirection. (But it looks better with a space, and avoids confusing cases e.g. echo text1>file and echo text 1>file)
yes if i run the comand manualy is work but the cron not work
on /etc/cron.d is mylicense file with this code
0 1 * * * root /usr/bin/mylicense
Why isn't this post marked as AI/LLM-generated? 
(I'm sorry, the style of your reply resembles style of AIs very much)
OK, thanks. And is the cron job producing any output, if you check the local mailbox for root on the system ?
no producing any output
OK, in that case further debugging is required. Can you change the cron job to re-direct standard output and standard error to separate files, so you can see exactly what output the binary is generating when run via cron ? So a line like this, essentially, for your cron.d entry:
0 1 * * * root /usr/bin/mylicense >/tmp/mylicense.out 2>/tmp/mylicense.error something similar. You could then examine the files created in /tmp and see what they contain after the cron job has run.
i get this error /usr/bin/mylicense: line 20: plesk: command not found
and i have this on line 20
plesk php mylicense
Shell does not make up command names. That was downloaded inside the script you are getting from https://xxx.com/mylicense. It is difficult to know how to help when you download a script from a site whose domain you obscure, and which can be changed by a third party any time they choose. How do you know this is not malware ?
As it happens, there is a Plesk product, but you probably want to verify its authenticity before you install anything.
Plesk is a commercial web hosting and server data center automation software developed for Linux and Windows-based retail hosting service providers.
The software is licensed, and with that comes unlimited free support. You should use that facility.
That would tend to imply either that Plesk is not installed, or that the plesk binary is not in the path of the cron job's runtime environment. It's been a few years now since I routinely administered Plesk, but I think from Obsidian onwards the default location for that binary is /usr/sbin/plesk. Can you try using the full paths to all binaries in your script, or modifying your cron job to include /usr/sbin (or whatever other directory this binary is installed in) in its path ?
i thing is a script issue because on cron.d/mylicense is show only this
0 1 * * * root /usr/bin/mylicense
but if i edit the cron manualy and add this to cron run
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
0 1 * * * root /usr/bin/mylicense
the script dont put this line to cron
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin