Bug 995590 - Cron job runs, but doesn't do anything
Cron job runs, but doesn't do anything
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cronie (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-09 15:18 EDT by Peter Gückel
Modified: 2013-09-29 20:50 EDT (History)
5 users (show)

See Also:
Fixed In Version: cronie-1.4.11-4.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-25 09:29:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed fix (1.24 KB, patch)
2013-08-16 11:11 EDT, Jaroslav Škarvada
no flags Details | Diff
Proposed fix for one memory leak (379 bytes, patch)
2013-08-16 11:16 EDT, Jaroslav Škarvada
no flags Details | Diff

  None (edit)
Description Peter Gückel 2013-08-09 15:18:13 EDT
Description of problem:
I have set up a user cron job in /var/spool/cron/peter that runs the following:

0 11,12,13,14,15,16,20,21,22,23 * * * /home/peter/bin/motivator.sh

The permission of /var/spool/cron/peter:

-rw-------. 1 peter peter 101 Aug  3 11:27 peter

The script, motivator.sh, is a one-line program:

espeak "take a break"

/var/log/cron shows that the program ran successfully, but no sound is emitted:

Aug  9 13:00:01 desk CROND[9437]: (peter) CMD (/home/peter/bin/motivator.sh)

Version-Release number of selected component (if applicable):
cronie-1.4.10-5.fc19.x86_64
espeak-1.47.11-2.fc19.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
This always worked in all previous Fedoras, but has ceased to work in Fedora 19.

I had thought that the problem had something to do with selinux, but they say the problem is resolved and have closed the bug, bz#986140, despite the problem persisting.

I haven't tried it on my laptop, i686, but I suspect that the problem is there, too.
Comment 1 Tomas Mraz 2013-08-12 06:19:15 EDT
Have you tried to do something else in the motivator.sh script? This might be affected by other things than SELinux - for example pulseaudio or policy-kit changes.
Comment 2 Peter Gückel 2013-08-12 11:13:17 EDT
Like what, for example?

My full /var/spool/cron/peter file actually has 2 lines. one line runs the motivator.sh script and the other line runs my bu.sh (backup) script. That one also runs, like the motivator script, without errors, according to /var/log/cron, but it actually does something.
Comment 3 Marcela Mašláňová 2013-08-12 11:18:55 EDT
I do not use esound. Does esound work? Does cronjob with esound work when you set setenforce=0 and restart cron daemon?

Usually, it's very hard to debug why user's cronjobs are not working.
Comment 4 Peter Gückel 2013-08-12 11:22:46 EDT
I don't have esound and esound is not in the fedroa repositories. man esound turns up nothing.

What happens on your test computer when you set up a cronjob that calls espeak?
Comment 5 Marcela Mašláňová 2013-08-12 11:43:54 EDT
I'm sorry, I meant espeak. It works for me from command line, it doesn't work even without SElinux from cronjob. But that might be because of many other things, which I do not plan to investigate (pulseaudio, policy-kit). Maybe espeak maintainer has some idea?
Comment 6 Peter Gückel 2013-08-12 12:39:40 EDT
It works for me from the command line, too. It also doesn't work for me with selinux disabled.

Why does nobody want to fix this?
Comment 7 Marcela Mašláňová 2013-08-13 03:07:21 EDT
Feel free to send a patch. I have no idea how sound is working.
Comment 8 Jaroslav Škarvada 2013-08-13 10:52:48 EDT
It seems that PulseAudio requires XDG_RUNTIME_DIR environment variable to be correctly set. Try to change the crontab command the following way:

XDG_RUNTIME_DIR=/run/user/`id -u` espeak "take a break"

Or you can bypass the PulseAudio and use ALSA directly (but it may cause resource conflicts if used without dmix):

espeak --stdout "take a break" | aplay -q -Dplughw:0

Cronie could export the XDG_RUNTIME_DIR (guess its content) when executing user's crontab, but it will work only for the time the user is logged in. Full support would require registering the session / talking to systemd-logind through PAM (namely pam_systemd module), which could lead to more troubles and is probably not worth to implement into cron.
Comment 9 Peter Gückel 2013-08-13 11:28:26 EDT
I put the command:

XDG_RUNTIME_DIR=/run/user/`id -u` espeak "take a break"

into my script and...

It worked!

1. You said that "cronie could export the XDG_RUNTIME_DIR when executing user's crontab. How would that be done? It only needs to be set when the user (me) is logged in.

After a bit of fiddling/thinking, I noticed that it already is set by default anyway:

echo $XDG_RUNTIME_DIR

shows:

/run/user/1000

So, why doesn't cronie honour the setting?

2. I could just run the fixed script. Now I know how to do it.

But, I still am curious to know why cronie doesn't recognize the value of XDG_RUNTIME_DIR.
Comment 10 Tomas Mraz 2013-08-13 11:41:27 EDT
(In reply to Peter Gückel from comment #9)

> echo $XDG_RUNTIME_DIR
> 
> shows:
> 
> /run/user/1000
> 
> So, why doesn't cronie honour the setting?

Because the cron jobs run in separate session which is not related to your user login shell session.
Comment 11 Jaroslav Škarvada 2013-08-16 11:11:48 EDT
Created attachment 787314 [details]
Proposed fix

Well, I just looked on the cronie code and the PAM support is already there.

It seems you are reading the PAM environment the wrong way.
Comment 12 Jaroslav Škarvada 2013-08-16 11:16:47 EDT
Created attachment 787324 [details]
Proposed fix for one memory leak

It seems the cronie code introduces several memory leaks. The attached patch should fix 8 bytes (or more according your PAM configuration) leak (counted on 64 bits), but it seems there are more leaks in the code.
Comment 13 Peter Gückel 2013-08-16 11:56:53 EDT
Comment 11 and Comment 12 : Are you sure you're on the right bug? The issue I  reported was determined to be due to the XDG_RUNTIME_DIR and it has been solved by using the workaround you suggested in Comment 8.

I am now lost. Are you suggesting that if I apply the 2 patches, I would not need to export the XDG_RUNTIME_DIR in the crontab file, as you showed me how to do in Comment 8?
Comment 14 Tomas Mraz 2013-08-16 12:09:05 EDT
I've fixed the problem of not pulling the PAM environment variables from the session modules slightly differently in upstream commit here:

https://git.fedorahosted.org/cgit/cronie.git/commit/?id=c8e7d1b43c86a85441cb09cf7e08090f3ec1f384
Comment 15 Tomas Mraz 2013-08-16 12:10:00 EDT
(In reply to Peter Gückel from comment #13)
> Comment 11 and Comment 12 : Are you sure you're on the right bug? The issue
> I  reported was determined to be due to the XDG_RUNTIME_DIR and it has been
> solved by using the workaround you suggested in Comment 8.
> 
> I am now lost. Are you suggesting that if I apply the 2 patches, I would not
> need to export the XDG_RUNTIME_DIR in the crontab file, as you showed me how
> to do in Comment 8?

The workaround will be needed till we build a fixed cronie package and do Fedora update.
Comment 16 Peter Gückel 2013-09-06 11:15:00 EDT
(In reply to Tomas Mraz from comment #15)
> The workaround will be needed till we build a fixed cronie package and do
> Fedora update.

I have been out of the loop. Has a fixed cronie package been issued? Is the workaround still needed?
Comment 17 Karel Volný 2013-09-25 09:18:12 EDT
FYI, there is similar problem ("job runs but doesn't do anything") with awstats, see bug #1009379

after removing /dev/null redirection (bug #1011599 FTR) I'm getting these errors:

Running '"/usr/share/awstats/wwwroot/cgi-bin/awstats.pl" -update - config=dze.hajnet.cz -configdir="/etc/awstats"' to update config dze.hajnet.cz
Eerror: AWStats database directory defined in config file by 'DirData' parameter (/var/lib/awstats) does not exist or is not writable.
Setup ('/etc/awstats/awstats.dze.hajnet.cz.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory).


but the directory /var/lib/awstats *is* writable from the cron script (see bug #1009379 comment #5)

the env is:

MAILTO=root                                                                                                                                                                                                    
SHELL=/bin/bash                                                                                                                                                                                                
USER=root                                                                                                                                                                                                      
PATH=/sbin:/bin:/usr/sbin:/usr/bin                                                                                                                                                                             
_=/bin/env                                                                                                                                                                                                     
PWD=/root                                                                                                                                                                                                      
LANG=cs_CZ.UTF-8                                                                                                                                                                                               
SHLVL=3                                                                                                                                                                                                        
HOME=/root                                                                                                                                                                                                     
LOGNAME=root


... no XDG_something set
Comment 18 Fedora Update System 2013-09-25 09:22:05 EDT
cronie-1.4.10-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cronie-1.4.10-6.fc19
Comment 19 Fedora Update System 2013-09-25 09:34:56 EDT
cronie-1.4.11-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/cronie-1.4.11-4.fc20
Comment 20 Tomas Mraz 2013-09-25 10:00:26 EDT
Karel, I don't think this is related.
Comment 21 Fedora Update System 2013-09-27 01:41:39 EDT
cronie-1.4.10-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cronie-1.4.10-7.fc19
Comment 22 Karel Volný 2013-09-27 06:14:38 EDT
(In reply to Tomas Mraz from comment #20)
> Karel, I don't think this is related.

you're right, that one seems like a pure selinux issue now
(and I've just confirmed that the new cronie doesn't change a bit on that issue)
Comment 23 Fedora Update System 2013-09-28 21:47:06 EDT
cronie-1.4.10-7.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Fedora Update System 2013-09-29 20:50:44 EDT
cronie-1.4.11-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.