Description of problem: Under certain circumstances systemd stops running stuff, e.g. mrtg, while the old way of using crond would still run mrtg. Version-Release number of selected component (if applicable): systemd-37-17.fc16.x86_64 How reproducible: have a data source for mrtg have a hiccup once in a while so that mrtg gives an error. mrtg might exit, but this does NOT dismiss systemd of runnign mrtg the next time at the end of the interval. compare with old crond behaviour. Actual results: See below Expected results: mrtg being started after the error and after the time has passed to do so again. Additional info: Apr 6 15:49:52 surfplank2 mrtg[26983]: can't read "expect_out(buffer)": no such variable Apr 6 15:49:52 surfplank2 mrtg[26983]: while executing Apr 6 15:49:52 surfplank2 mrtg[26983]: "send "$expect_out(buffer)" " Apr 6 15:49:52 surfplank2 mrtg[26983]: 2012-04-06 15:49:47: WARNING: Problem with External get 'expect -c 'set timeout 4; expect -re "GPGGA(.*)\n"; send "$expect_out(buffer)" ' < /dev/ttyS2|/bin/grep -m 1 GPGGA|cut -d, -f8; echo 0': Apr 6 15:49:52 surfplank2 mrtg[26983]: Expected a Number for 'out' but nothing' Apr 6 15:49:52 surfplank2 mrtg[26983]: 2012-04-06 15:49:52: ERROR: Target[gpssat][_OUT_] ' $target->[13]{$mode} ' did not eval into defined data Apr 6 15:49:52 surfplank2 mrtg[26983]: Use of uninitialized value $outlast in pattern match (m//) at /usr/bin/mrtg line 1047. Apr 6 15:49:52 surfplank2 systemd[1]: mrtg.service: main process exited, code=exited, status=91 Apr 6 15:49:52 surfplank2 systemd[1]: Unit mrtg.service entered failed state.
only mrtg.timer is being used, so why the systemd happenings with mrtg.service? Xorg crashed just before but that should not be a reason for systemd to do anything with the processes running. mrtg had this issue. rsyslogd exited. ntpd exited. etc. Why?
What does this command show after the error happens?: systemctl status mrtg.timer mrtg.service And what does the command show 5 minutes later?
My Xorg does not crash every day but I will pay attention when it does.
I thought you had a reproducible way to make mrtg hiccup and that it was sufficient to make the bug show. I could not reproduce the bug with a test pair of .service/.timer units where I intentionally made the service fail. The timer unit ensured the service was run again at the end of the next interval. I don't know how to explain the Xorg+rsyslog+ntpd crash nor how it can relate to the mrtg problem. Could you attach the whole /var/log/messages from which you pasted the part in comment #0 ?
I rewrote that part of mrtg.cfg and did not see the error in the ntp part. (the log in the bug report) I do see though that the mrtg main process exit with status 91 (due to the timing and type of work being done, so more or less understandably) but then it gets the failed state by systemd. This happens when e.g. mrtg does not get at least one item of the expected data (as shown in the first report) This error state should not be a reason to stop running mrtg or any other process managed by systemd. This is also true for the info in comment 1 where an external event (Xorg issue) perhaps caused situations to temporarily change.
So let me get this right: sometimes if a service unit fails the timer unit stop starting the service the next time? What is the contents of you timer and service units? Please attach or paste.
I believe these files are Redhat Fedora stock: $ cat /lib/systemd/system/mrtg* # To customize, copy this file to /etc/systemd/system and edit there # # This unit facilitates starting of MRTG. There are 2 options of # how to run MRTG: # - as a daemon (preferred); in this case please put # RunAsDaemon: yes in mrtg.conf (or use --daemon switch) # - periodically - please see and enable mrtg.timer # Periodic settings need Type=oneshot set here # # Other recommended settings in mrtg.cfg for daemon mode: # NoDetach: yes # If you set this, change below Type=simple # # Please disable /etc/crond.d/mrtg job when using this unit! # # do not enable both mrtg-as-a-daemon and timer at the same time [Unit] Description=Multi-router Traffic Grapher After=syslog.target [Service] Environment=LANG=C ExecStart=/usr/bin/mrtg /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache-file /var/lib/mrtg/mrtg.ok # Type= settings cheatsheet: # - RunAsDaemon: yes; NoDetach: yes : #Type=simple # - RunAsDaemon: yes; NoDetach: no : #Type=forking # - RunAsDaemon: no; (periodic invocation) : #Type=oneshot Type=simple StandardOutput=syslog [Install] WantedBy=multi-user.target # To customize, copy this file to /etc/systemd/system and edit there # # You can use this unit to periodically run mrtg.service. # Only enable if you do not want to run mrtg as a daemon. # Starting mrtg.timer while mrtg.service is running as a daemon has no point. # # Please disable /etc/crond.d/mrtg job when using this unit! # # Default is to run mrtg.service every 5 minutes, starting # 1 minute after system boot. [Unit] Description=periodic invocation of MRTG [Timer] OnBootSec=1m OnUnitActiveSec=5m [Install] WantedBy=multi-user.target
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is fixed in git/soon in F19.
systemd-203-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-203-2.fc19
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Package systemd-201-2.fc18.6: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.