Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

bavodog · 2015-10-06 19:37:27

Hello all!
I am new here, so if I am not doing this right, would someone please speak up?

I am having an issue with cron, or rather the lack thereof...

OK, so I got Plasma5 up and running on my new laptop, which was easy and the install went without a snag. And so there I am exploring the newness of it all and after clicking the "Application Launcher" I am rewarded with a window containing my user name, a search field, and a list of favorite programs. I am sure everyone who uses Plasma5 is familiar...

So I click into the search field underneath of my username and a quick search for "cron" turns up the KDE Task Scheduler, which I happily cllick on and am immediately rewarded with the KDE Task Scheduler. Fair enough.

I create a new task for it to run (/usr/bin/reboot) and the task is created and set to run in five minutes. The joy I feel is unexampled, and then i hit the "Apply" button and my joy is immediately replaced with an error message that says simply...

"There was an error."

Clicking on "Details" reveals even more helpful insight...

ERROR

Aa quick searching of the interwebs reveals the following page....

https://docs.kde.org/trunk5/en/kdeadmin … index.html

...which reminds me to search for which cron I have installed so that I may enable it....

"$ which cron" returns the following

which: no cron in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

and I check /etc/* for crontab or cron.d or something but nothing is there. /var/spool/* is devoid of anything cron-ish too

So I install cronie with pacman, and i enable it, and I start it, and it seems to work! the error from KDE Task Scheduler no longer and I can happily create new tasks without error messages and the folder /var/spool/cron/ as well as well as the "user" file is getting updated with each new task as I create them. I recreate the taks I just created to retest it and five minutes goes by and nothing happens, again. after several attempts and trys to recreate the task, nothing persists in happening, and slowly I come to the realization that this just is not working..

So I restart the thing and check the status of cronie and systemctl says its running happily. KDE Task Scheduler happily creates the new task on the user file in var/spool/cron/, but the task never starts or runs. Any so, here I sit with no joy.

Am I hitting the proverbial permissions wall here or is there some issue or bug with Plasma5 that prevents one from using cron?

Any thoughts or insight would be superb!

Cheers and many thanks in advance

ewigkeit · 2015-10-08 05:34:18

Hi there, bavadog and welcome!
I am using cronie too, because it comes with anacron, a tool better suited for desktop machines and laptops. Cron itself is more usefull for servers.

Could you please post the output of:

# systemctl status -l cronie

$ crontab -l

# crontab -l

It might also be good practice, to edit cronjobs directly with "crontab -e". I know, the format of a crontab might be challenging at first glance, but it's a piece of cake, if you take five minutes to read and understand it. A pretty good guide is the corresponding Wiki-Page.

byte · 2015-10-08 17:50:39

https://wiki.archlinux.org/index.php/Systemd/Timers should explain your unsuccessful search for cron-related things in the 'systemd land' that is Arch.

bavodog · 2015-10-08 19:45:36

Sure thing ewigkeit!

The terminal says....

[user@puppet ~]$ systemctl status -l cronie
● cronie.service - Periodic Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/cronie.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2015-10-08 13:33:53 CDT; 23min ago
Main PID: 369 (crond)
CGroup: /system.slice/cronie.service
└─369 /usr/bin/crond -n

Oct 08 13:33:54 puppet crond[369]: (CRON) INFO (Syslog will be used instead of sendmail.)
Oct 08 13:33:54 puppet crond[369]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 62% if used.)
Oct 08 13:33:54 puppet crond[369]: (CRON) INFO (running with inotify support)
Oct 08 13:33:53 puppet systemd[1]: Started Periodic Command Scheduler.

[user@puppet ~]$ crontab -l
#comment
0 20 * * * /home/user/Software/reboot

# File generated by KCron the Wednesday, October 7, 2015 7:58:26 PM CDT.

...not sure why you had me run crontab -l twice, but the result was exactly the same the second time...

Does that help?

Thank you byte from Düsseldorf (DE) for the link, but I have visited that page several times and I have read it up and down. I am just not seeing what I am looking for, or at, as it were. Clearly, I am missing something.

Thanks a bunch for helping me with this, folks! I actually feel a little sheepish not being able to see the issue (posting in a forum to ask for help is generally a measure of last resort for me! I hang my head in shame...) but to be fair this really is a brand new OpSys to me, and the biggest issue I have had thus far has been configuring the voice recognition, and this.

And I actually whipped the voice recognition into a bloody and submissive pulp yesterday so I am pretty proud of that...but cron is still tying the long hairs on my neck to the short hairs on my butt and kicking me backwards down the street. It really is getting a little old after, like 2+ months of this. I have been trying to get a working cron-scheduler going since my first KDE Plasma build...many many moons ago.

Cheers and thanks again for any insight you can offer!

Buddlespit · 2015-10-08 21:05:57

I've had no success with user timers in systemctl, so I'm also running cron jobs. I have no problems running system and user cron jobs, but I'm also opening systemsettings5 as root to set up the system cron jobs. What jobs are you running that are failing?

bavodog · 2015-10-08 22:16:46

Buddlespit wrote:

I've had no success with user timers in systemctl, so I'm also running cron jobs. I have no problems running system and user cron jobs, but I'm also opening systemsettings5 as root to set up the system cron jobs. What jobs are you running that are failing?

All of them are failing, giving me a grand total of one....so to be fair, it is "job" not "jobs".

I have only included the one because that is as far as I got. When the one would not work I deduced that two or three or eighteen would be pointless. It is just a simple reboot sequence that calls /usr/bin/reboot at such and such a time. I would settle for it rebooting at ANY time at this point, or running ANY command at ANY time as long as I could determine what and when.

Besides cronie, I have tried playing with systemctl timers, fcron, anacron...

Just to give you an idea of how long I have been failing at this, I even found and tried things like this...

echo "/usr/bin/reboot" | at midnight

which seemed pretty clever, but failed because my machine does not like the at command.

And then there was...

at midnight<<<'/usr/bin/reboot'

which I also thought was clever, but again, there is that "at" command that my shell does not like.

I even found this little golden snippet of code I believed at one time might just be helpful to help me figure out what was what....

for USER in `cut -d ":" -f1 </etc/passwd`; do crontab -u ${USER} -l 1>/dev/null 2>&1; if [ ! ${?} -ne 0 ]; then echo -en "--- crontab for ${USER} ---\n$(crontab -u ${USER} -l)\n"; fi; done

...which once again, appears to be very , very clever, but which ultimately takes me nowhere and leads me to nothing.

I really have been trying to iron this out for a while. Cronie and gnome task scheduler work like a dream in Gnome...but on KDE it is a different animal apparently.

it leaves me totally stumped.

Buddlespit · 2015-10-09 02:13:49

are you running the reboot as root or as user?

ewigkeit · 2015-10-09 04:57:50

First things first. Especially for an Arch User, it is advantagous, to bring some solid knowledge about Linux into the equation, because Arch is no beginner distro.

After saying that, let me give you some tips to better get along in the forums the next time, to save others some time:

1.

$ crontab -l #run command as user

# crontab -l #run command as root

Please notice the difference in the beginning of the lines ($ and #)!

2. Always put the output of the terminal between code-Tags

Now the crucial part. Your added crontab seems to be the problem for me, because it tries to run the reboot command from some unknown user directory.
Follow these steps and try again:

$ EDITOR=nano crontab -e

now change the /home/user/Software/reboot part to /usr/bin/reboot and edit the time format, if you just want to check, if the command is running in the next few minutes.

0 20 * * * -> means the command runs every day at 20:00

By the way… if you just want a terminal command to reboot a machine at a certain time, you could always use

$ shutdown -r 20:00

---
Edited because of typos and correction for a better unterstanding

Last edited by ewigkeit (2015-10-09 07:22:10)

bavodog · 2015-10-09 08:01:34

ewigkeit wrote:

First things first. Especially for an Arch User, it is advantagous, to bring some solid knowledge about Linux into the equation, because Arch is no beginner distro.

Church. True that.

ewigkeit wrote:

After saying that, let me give you some tips to better get along in the forums the next time, to save others some time:
1.
$ crontab -l #run command as user
# crontab -l #run command as root
2. Always put the output of the terminal between code-Tags

oh, right. I had no idea. I clicked the BBCode link below and found code for a bunch of colors when I was looking for tags and i guess I thought any tags would do and just went with it and never scrolled down the page. I did in fact tag everything; just not with code tags. I take your point though. Wont happen again.

ewigkeit wrote:

Now the crucial part. Your added crontab seems to be the problem for me, because it tries to run the reboot command from some unknown user directory.

Yeah, I thought about that after I posted it, but probably not for the same reason you may think. You see, that particular user directory is home to an assortment of automation tools, not the least of which is an exact copy of the file known as /usr/bin/reboot that was created by me in an attempt to figure out why cronie wasnt running anything. typing /home/user/Software/reboot in a terminal has exactly the same effect as typing /usr/bin/reboot without having to access a file in any root directory.. My thinking was that perhaps permissions were a problem and running reboot from a user folder would help....but I never considered that doing so would add to the confusion. Please rest comfortably in the knowing that I have, in fact, tried it numerous times with every command I can think of, including /usr/bin/reboot, reboot, shutdown -r.

All of those commands work brilliantly if I just enter them into the command line, but if I try to run them with cronie (or rather cronie via my favorite cron editor KDE Task Scheduler). I get why you have a problem with me trying to run a file located in a user directory, but believe me when I say that is not the only way I have tried. I have been trying to get this to work for weeks. I am telling ya; cronie or the cron service or something is hosed, not the nut behind the wheel. The nut behind the wheel is tight.

ewigkeit wrote:

Follow these steps and try again:
$ EDITOR=nano crontab -e
now change the /home/user/Software/reboot part to /usr/bin/reboot and edit the time format, if you just want to check, if the command is running in the next few minutes.

Done exactly as you directed. I set it to reboot using /usr/bin/reboot in three minutes, but it wont. I am so confident that it wont that I am going to keep on typing and risk losing everything I have written in this post when my system reboots in a couple of moments....

...as I was saying.

ewigkeit wrote:

By the way… if you just want to a terminal command, to reboot a machine at a certain time, you could always use
$ shutdown -r 20:00

now see, this snippet of code I find really interesting. This I may be able to use temporarily, although I would really rather have cron working. The machine we are talking about here is an attempt to build a KDE based "backup clone" of a puppet-server running Gnome that relies heavily on "scheduling" with cronie, so the ability to migrate as opposed to recreate is preferable. You asked about

# systemctl status -l cronie

and I replied with the output. Did that ouput tell you anything? I really want to understand this so I can recreate it on 7 other machines that all have the exact same issue (no cron installed--any cron I install refuses to run anything, ever) out of the box with kde plasma5.

...and I just realized that I may have misunderstood your request when you said...

$ crontab -l

# crontab -l

$? #?

According To my best understanding. $ is used in constructing variables and # denotes numbers, she-bangs, and comments, but the idea that they can also be used to denote root or user is completely new and foreign to me! I have seen both used like that before, but I always ignored/omitted them out of the assumption that it was denoting a blinking cursor and the command began after the #/$. I have seen cursors blinking with both symbols on different systems like on youtube videos and whatnot...but mine has always been just a square...

wow! I wonder how much code i have botched up not realizing that....

You will forgive me for being something of an educated moron. 5+ years on a much less powerful, less popular linux distro (not Arch) that ran on a live CD as root and used no sudo or su commands at all (and a very limited amount of software packages with nearly no hope of ever building packages for it or modifying existing packages) has taken its toll on dumbing me down considerably in the ways of UNIX formatting. I do realize that I know just enough about programming to be incredibly dangerous on an Arch build. I have never before in my life began a command with a # or a $ on a unix system unless I was writing a comment or a variable, but that isnt saying much. I have only been writing code (I have written code before, lots of times, maybe a line or twenty here and there, but Arch forces you to write freakin code like crazy madness, just because you can!!!) like this for a few months, so...theres that.

I am a former Master Electrician who turned into an Automated Systems Engineer before I went blind and started playing with computers, but upuntil recently, with the exception of 20 some odd years installing and programming P.L.C.'s I have been into hardware primarily. Only recently have I gotten into software modification and development, and only about 3 months ago did I learn that there even was a difference between a user and root, so try not to judge too harshly. I am an old dog learning to do new tricks on a very steep curve...

I wonder if this would work...

/usr/bin/reboot 20:00

...but then, after hearing from you, I have doubt. Maybe I should rather use this instead

# /usr/bin/reboot 20:00

....or this...

$ /usr/bin/reboot 20:00

awww... bollox.

Thank you, ewigkeit. You have just completely blown my mind.

I am off to bed to process this! pretty sure this problem will still be here when I awake, and besides that, you have given me a lot to think about which I should absolutely sleep on.

Cheers and thanks again ewigkeit!

ewigkeit · 2015-10-09 08:37:30

No judging on my side, I just want to help you get along on the way. Some people might be a little rough around Linux boards *cough, cough*

---

In forum posts and blog articles it is common practice to use an upfront $ to tell users that you run a command savely as a user. If you ever find a # upfront, it means run as root, for example:

# crontab -l

could mean you just type

sudo crontab -l

You NEVER type the upfront $ or # directly in the terminal… it should already be the final symbol in the line, before you type. It's just supposed to tell you, how to run a command (as user or as root), because that makes a huge difference. But not everyone has sudo installed and configured, so some have to use su and work with that!
But all this has absolutley nothing to do with configuration files or programming!
You are right, that for that subjects, $ and # mean totally different things!

---

bavodog wrote:

I wonder if this would work...
/usr/bin/reboot 20:00
...but then, after hearing from you, I have doubt. Maybe I should rather use this instead
# /usr/bin/reboot 20:00
....or this...
$ /usr/bin/reboot 20:00
awww... bollox.
Thank you, ewigkeit. You have just completely blown my mind.
I am off to bed to process this! pretty sure this problem will still be here when I awake, and besides that, you have given me a lot to think about which I should absolutely sleep on.
Cheers and thanks again ewigkeit!

Please forget this as fast, as you thought about it. The reboot-command doesn't work with a time argument, as far as I know. Only the shutdown-command works that way. So, if I did get you right, you already tested

/usr/bin/shutdown -r 20:00

and it worked, which leaves me pretty clueless for the moment. If something else comes to my mind, I will let you know.

Last edited by ewigkeit (2015-10-09 08:44:28)

bavodog · 2015-10-09 19:30:29

Yep. First, I tried

$ shutdown -r 2:00

which resulted in the terminal informing me that "$" is not a command.

I then tried

# shutdown -r 2:00

...after which exactly nothing happened. and why should it? I just made a ##comment to the terminal, which it has rightfully ignored because of the hashtag.

So, i tried....

shutdown -r 2:00

which got me

Must be root.

So, i tried

sudo shutdown -r 20:00

and that worked brilliantly!

Shutdown scheduled for Fri 2015-10-09 20:00:00 CDT, use 'shutdown -c' to cancel.

So, that at least gives me a way to shut the thing down and reboot it programatically. Thanks for that!

but, fyi, running...

sudo /usr/bin/reboot 20:00

...simply resulted in my computer being shut down immediately, ignoring the time and running reboot as root.

So there you are! All absolutely fascinating, yet all ultimately leaving me right back where I was.

I thank you for the help ewigkeit, yet I ask again...

Your first reply to my post asked me to enter "systemctl status -l cronie" and to post the results, and I did.

What was the point of entering "systemctl status -l cronie", what does the output tell us, and what should I try next? There has to be a process to troubleshoot cronie, or crontab, or whatever seems to be borked here.

I would very much like to understand that process...

any thoughts?

Cheers and thanks again!

ewigkeit · 2015-10-10 05:50:54

As I told you before, you don't type any of $ or # in your terminal. It should already be the last symbol of your prompt.
But the real problem seems to be, that you don't have permission to execute power related commands as a normal user.

Following the wiki, you can use these instuctions, to gain that permission als a regular user: https://wiki.archlinux.org/index.php/Al … emd-logind

Another method would be, that you handle power oriented tasks with cron as root. So you would have to

sudo crontab -e

and add a corresponding crontab.

bavodog wrote:

Your first reply to my post asked me to enter "systemctl status -l cronie" and to post the results, and I did.
What was the point of entering "systemctl status -l cronie", what does the output tell us, and what should I try next?

The systemctl command just told me, that cronie is really up and running. No secret magic there.

bavodog · 2015-10-10 08:10:35

ewigkeit wrote:

As I told you before, you don't type any of $ or # in your terminal. It should already be the last symbol of your prompt.

Got it.

ewigkeit wrote:

But the real problem seems to be, that you don't have permission to execute power related commands as a normal user.

I could be wrong, but IMO the problem is that I cannot issue any commands with cron at all, period. Including power commands, but not limited only to power commands; also I cannot run custom scripts, I can not run customized volume control, none of my automation tools will run with cron, and they also wont run without it.

I install cron, I systemctl enable it and start it, I sudo systemctl enable and start it after that, and I get zip, nada goose egg, even when I try to schedule the most basic of commands.., but let me be clear. The crontab file contents (that I plan on copying over the one-liner reboot command I am trying to run now) is some 720+ lines long and growing. please do not get lost in the reboot command...I mean, its an important command and I need it to work and all, but it is one of many, and I mean to tell you that absolutely none of them work. I am focused on the reboot command only out of simplicity in communicating my problem, but it much bigger than just power permissions I believe.

If I were a betting man, my money would be on cron not having permissions/priveledges to execute commands...but I am not sure how to go about adding permissions and privs to a program. Does cron run as user, as root, or as something else? Does that make sense?

to make cron work on gnome, I had to do some "xhost +local" or some crazy command like that (i can look it up if need be, it is in a history log) to get cron to work, but that did not work on KDE. Could it be something with xhost?

It may be that I haven't the faintest clue what I am doing or what is what...or it may be that I installed something wrong or failed to install something that needs installing...I am honestly not sure.

I checked the link you referred to and read the page. I even shut down my computer from the command line using systemctl, but I learned nothing that would help me with my problem. Thanks tho! I had not read that particular page yet, and the information is indeed invaluable, if not also inapplicaple in this instance.

Either way I appreciate your help in figuring it out. Thanks again again!

I am going to sleep on it some more....

Cheers!:)

::::MORNING EDIT::::

it is worth mentioning that running...

crontab -e

...produces much different results than running...

sudo crontab -e

??

crontab -e produces this...

#No comment
50 22 * * *     /usr/bin/reboot


# File generated by KCron the Friday, October 9, 2015 10:49:11 PM CDT.
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
"/tmp/crontab.xc5zth" 5 lines, 113 characters

while sudo crontab -e produces this...

# root crontab
# DO NOT EDIT THIS FILE MANUALLY! USE crontab -e INSTEAD

# man 1 crontab for acceptable formats:
#    <minute> <hour> <day> <month> <dow> <tags and command>
#    <@freq> <tags and command>

# SYSTEM DAILY/WEEKLY/... FOLDERS
@hourly         ID=sys-hourly   /usr/bin/run-cron /etc/cron.hourly
@daily          ID=sys-daily    /usr/bin/run-cron /etc/cron.daily
@weekly         ID=sys-weekly   /usr/bin/run-cron /etc/cron.weekly
@monthly        ID=sys-monthly  /usr/bin/run-cron /etc/cron.monthly

~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
"/tmp/crontab.d0Yg0p" 13 lines, 509 characters

I totally recognize the crontab -e version but the sudo crontab -e version is new and greek to me. Whats up with that I wonder?

........strange.......

Last edited by bavodog (2015-10-10 16:49:56)

raygenbogen · 2015-10-20 15:02:16

running

crontab -e

lets you edit your cronjobs as a user. And the only job in your crontab is the reboot command, which won't work since you don't have the right permission for this.
running

sudo crontab -e

shows you the cronjobs of root. and this is just empty so it really does nothing. If you want to test a reboot, than add it in roots crontab and not your users.
So you don't tell cron which user should run a certain command. root will run the commands in his crontab and your user will run the command in your crontab.

Arch Linux

#1 2015-10-06 19:37:27

Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#2 2015-10-08 05:34:18

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#3 2015-10-08 17:50:39

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#4 2015-10-08 19:45:36

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#5 2015-10-08 21:05:57

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#6 2015-10-08 22:16:46

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#7 2015-10-09 02:13:49

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#8 2015-10-09 04:57:50

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#9 2015-10-09 08:01:34

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#10 2015-10-09 08:37:30

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#11 2015-10-09 19:30:29

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#12 2015-10-10 05:50:54

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#13 2015-10-10 08:10:35

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

#14 2015-10-20 15:02:16

Re: Plasma and crond, cronie, fcron, crontab and KDE Task Scheduler?

Board footer