These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Webmin 1.921 and Usermin 1.771 released on the new forum.
Howdy all,
I've rolled out new versions of Webmin and Usermin for all repositories. It's been a while since we've pushed updates of Webmin and Usermin to the Virtualmin repo (because of some minor performance bugs introduced by new features), so there are a few releases worth of changes (though the most significant changes are in the included theme updates):
Webmin changes:
Version 1.921
Version 1.920 (6th July 2019)
Version 1.910 (9th May 2019)
Usermin changes:
As always, let us know if you run into any problems. Pro users can open a ticket in the issue tracker, or GPL users can start a new forum topic (though bugs are always welcome in the issue tracker here or at github).
Cheers,
Joe
Hello, The webmin version 1.921-1 when installed does not work Cron Jobs.
I tested it from a clean installation, and it always gives me the same result.
My operating system is CentOS Linux 7.6.1810
regards
What is that result?
--Richard
it was a problem of the PHP script, with this version the cron jobs don't work
Do the cron jobs return error messages when triggered manually from within Webmin? If you click "Save and Run Now" from within "Edit Cron Job," even without making any changes, it should attempt to run the job. Do you receive any errors or warnings in the black box?
--Richard
RJM Web Design. First of all thank you very much. Is there a guide for webmin 1,921 and what does Crob Jobs work for? They really aren't working for me the log file doesn't give me an error
The 1.900 version I just have to add the Cron Jobs and they work!
a cordial greeting.
I don't know of any Webmin guides that are current beyond the official documentation at http://www.webmin.com/docs.html. I have a few books I bought from Amazon, but they're several years old.
As to your script, have you checked the permissions? Once in a while I forget I'm root and plant a script somewhere in the filesystem that can't be executed by the user because of ownership issues. I think that's probably the most common reason why a script (or a symlink, or whatever) "doesn't work," at least in my case.
So the first thing I'd do would be to cd into the directory that contains the script you're trying to execute, and check the ownership and permissions. A quick
ls -l
should do it. That will reveal both the ownership and permissions.Also, is this by chance a cron job you imported from cPanel? cPanel uses a non-standard path to PHP (usually something like
/usr/local/bin/ea-php70 /home/[user]/public_html/script.php
).If you plant that into Webmin (or any standard Linux system's crontab), it will do nothing. The path to PHP doesn't exist. So if this cron job was imported from a cPanel server, I'd try running it with
php -q /home/[user]/public_html/script.php
.I'd also suggest writing a simple script that does something like sends you an email and create a cron job for it to run every minute. If that script works but the one you're trying to cron doesn't, then you know it's a problem in the script.
--Richard
Thanks again. I come from Cpanel but I am installing everything from the beginning. with permissions you mean the file /usr/bin/crontab
a greeting
You're welcome.
I mean the permissions on the PHP script you're trying to execute. It has to be executable by the user you're trying to execute it as. You can find out by running
ls -l
while in the same directory as that file.In RHEL / CentOS, the crontabs are located in /var/spool/cron.
If you are root and want to list the cron jobs of a user, the command would be
crontab -l -u [user]
So if the user is bob,
crontab -l -u bob
Or to edit it,
crontab -e -u [user]
To list or edit the crontab of the user you are currently logged in as, it's simply
crontab -l
orcrontab -e
respectively.However, you should have no need to do any of this as it can be done through Webmin.
But I suppose it wouldn't hurt to list the crontab just for troubleshooting purposes. Just be careful in there if you're not used to working in the shell. Also, you may want to use nano rather than the default editor (usually vi) if you're new to the shell. Nano's a lot simpler for newcomers to the shell.
--Richard
I use PuTTy as a console. And if it's as root
Thanks Ricardo
I like PuTTy, but I LOVE Termius.
--Richard