Bug 995590
| Summary: | Cron job runs, but doesn't do anything | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Gückel <pgueckel> | ||||||
| Component: | cronie | Assignee: | Marcela Mašláňová <mmaslano> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 19 | CC: | jskarvad, kvolny, mmaslano, pertusus, tmraz | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| 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 13:29:42 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Peter Gückel
2013-08-09 19:18:13 UTC
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... 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. (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. 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.
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: https://git.fedorahosted.org/cgit/cronie.git/commit/?id=c8e7d1b43c86a85441cb09cf7e08090f3ec1f384 (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:
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
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 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 Karel, I don't think this is related. 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 (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. |