This is a freshly built slacker. I dropped in my cron files from my last distro into /etc/cron.d/. Unfortunately they don't run.

Also I don't see a cron service program in the /etc directory.

Is there a step involved in setting up cron? This topic appears to be blank:
https://docs.slackware.com/howtos:software:cron

I installed cronie, but the jobs still don't run. Do I really need cronie? I don't think so as it wasn't installed by default.

Is the crond deamon running? - check with:
It is launched from /etc/rc.d/rc.M during the init process

The cron files (make sure they're executable) that you have copied into /etc/cron.d/ should be copied accordingly into:
/etc/cron.daily/ /etc/cron.hourly/ /etc/cron.monthly/ /etc/cron.weekly/

Force crond to reread the configuration file (not really necessary as crond will do it by itself every minute), run as root:
and exit the vi editor by writing&exiting - type:

crond wasn't running.

The /etc/rc.d/rc.M has a statement

but crond doesn't even have a -l switch. I've decided to run crond by hand. I've made the cron files chmod +x but I'm reluctant to move them out of /etc/cron.d/ yet. The jobs still aern't running.

The crond man page disagrees with you about the -l switch. So does the crond executable.

The crontab files in /etc/cron.d are system wide, so username has to be present between day of the week and command fields. Sorry if you already knew it, but just in case...

2 members found this post helpful.

You should launch crond as it is launched in /etc/rc.d/rc.M and it has a -l switch, run man crond:
If you run crontab -e , as I suggested in my previous post, you'll notice that in the crond configuration file the scripts found in
/etc/cron.xxxx are executed:

P.S. Just wanted to confirm/point out again what @keefaz mentioned - crond has a per user configuration file and what I instructed you with was regarding the default root usage.
A good lecture:
http://www.unixgeeks.org/security/ne...ix/cron-1.html

Slackware uses Dillon's cron, which is not the same as Vixie cron or cronie. When copying /etc/cron.d jobs from a distro running Vixie or cronie, then those jobs will contain a user under which to execute the command. Adding a user name in /etc/cron.d jobs with Dillon's cron will cause cron to puke with exit status 127. Check the logs. Removing the user and restarting cron should get everything back to normal.

BTW, unlike other cron daemons, Dillon's cron does not acknowledge dynamic changes in /etc/cron.d. Dillon's cron must be restarted for /etc/cron.d changes to take effect.

If cronie is installed then dcron needs to be removed. Using cronie requires the user account in /etc/cron.d jobs. Dillo's cron does not.

1 members found this post helpful.

Just to add, crond stores the conf files (per user) in /var/spool/cron/crontabs/ - it'll create a crontab file with the username as its title.
Since you moved your scripts that cron was executing from your older system/distro, you should have also got the crontab files and put them in /var/spool/cron/crontabs/
Then run crontab -e to make sure crond got them. Alternatively, what I'm usually doing, I'm running crontab -e and I'm copy/paste-ing the old backed up crontab, this way I'm sure that crond will read (update the configuration) and store it correctly in the crontab file.

EDIT > Yup, I wasn't aware that the OP hasn't used Dillon's cron in the first place.

And, @upnort
You don't need to restart crond, just edit its crontab file and it will update by itself the next minute. The best way to do it is with crontab -e ---> this way it'll update instantly. And crond will execute all the modifications that one makes in the /etc/cron.xxxx folders, that are defined in the default root crontab, or any other previously user defined folder, without the need of updating its configuration (crontab -e for instance). It'll execute whatever it finds executable in the defined targets (folders) when the trigger time kicks in.

Thanks for the correction! I admit that I never used crontabs in /etc/cron.d. Hopefully your post will help to settle this

To OP, you can if you want but there is no need to merge the /etc/cron.d files into a root crontab because Dillon's cron is used. Just delete the user from the /etc/cron.d jobs, which likely for all of them will be root. Dillon's cron uses /etc/cron.d just fine. I have been doing that for years with Slackware and do not use a root crontab. I started doing this years ago when I had to support multiple distros and I wanted consistency between systems.

While /var/spool/cron/crontabs is supported with the other cron daemons, in other distros most folks do not use a root crontab for system jobs as is common in Slackware. With other distros /etc/cron.d and /etc/crontab are commonly used.

The crontab command is a per-user command. Dillon's cron will update itself automatically when using the crontab command, but not when modifying /etc/cron.d jobs. The other cron daemons see changes in /etc/cron.d dynamically. Dillon's does not.

@linuxbawks
While unport's inputs were very helpful in describing your issue and providing explanations for the alternatives to Slackware's standard crond (Dillon's cron) usage, depending on how confident you are to merge the configuration you've previously had into crond, I'd advise to do so. Some reasons, first I'd like to point out that Slackware uses crond for its housekeeping too and you'd need to merge those tasks into whatever crond alternative you choose, you're on the Slackware Forum looking for help and you'll be better off to get some if you're using the Slackware standard tools and the standard Slackware (old) Dillon's cron is just working fine and easy to use - flexible enough too.

Re-reading through your original post and the results that followed your investigation, especially that the crond was not running, the fact that you installed cronie and that you couldn't find the -l switch on crond, leads me to believe that your systems needs some cleaning. Uninstall cronie and check if your default crond (Dillon's cron) is still sane, if not reinstall it and start clean with your cron tasks merger/adaptations.

2 members found this post helpful.

Be aware [1], cronie conflicts with Slackware's dcron. In other words, if you installed cronie, you will have broken dcron, and if you remove cronie, you will need to reinstall dcron.

[1] https://slackbuilds.org/slackbuilds/.../cronie/README

2 members found this post helpful.

My experience has shown that new files can be added to /etc/cron.d/ and they ran. However a restart was required after removing files, else they continue to execute as scheduled. Since Slackware doesn't have a separate init script for crond, run: note the PID, then run: Hopefully others will find this information useful.

everything has been said in the various replies, your initial help request is puzzling though moving your cron root executable files into the appropriate directories should just work as always on a fresh slackware box.
you did move your files inside the proper location ? sorry it's not obvious to me

quite right there is no direct entry for cron on the docs site however this one on scheduling is there https://docs.slackware.com/howtos:ge...ing#using_cron to get the gist of as root