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: (peter) CMD (/home/peter/bin/motivator.sh)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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.
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.
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.
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.
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?
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?
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?
Feel free to send a patch. I have no idea how sound is working.
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.
I put the command:
XDG_RUNTIME_DIR=/run/user/`id -u` espeak "take a break"
into my script and...
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:
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.
(In reply to Peter Gückel from comment #9)
> echo $XDG_RUNTIME_DIR
> 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.
Created attachment 787314 [details]
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.
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 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?
I've fixed the problem of not pulling the PAM environment variables from the session modules slightly differently in upstream commit here:
(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.
(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?
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:
... no XDG_something set
cronie-1.4.10-6.fc19 has been submitted as an update for Fedora 19.
cronie-1.4.11-4.fc20 has been submitted as an update for Fedora 20.
Karel, I don't think this is related.
cronie-1.4.10-7.fc19 has been submitted as an update for Fedora 19.
(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)
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.
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.