Bug 810526 - systemd stops running tasks
systemd stops running tasks
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-04-06 10:24 EDT by udo
Modified: 2013-05-15 23:01 EDT (History)
7 users (show)

See Also:
Fixed In Version: systemd-201-2.fc18.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-15 23:01:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description udo 2012-04-06 10:24:48 EDT
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):

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.
Comment 1 udo 2012-04-06 10:33:07 EDT
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.
Comment 2 Michal Schmidt 2012-04-10 08:43:40 EDT
What does this command show after the error happens?:
systemctl status mrtg.timer mrtg.service

And what does the command show 5 minutes later?
Comment 3 udo 2012-04-10 09:31:11 EDT
My Xorg does not crash every day but I will pay attention when it does.
Comment 4 Michal Schmidt 2012-04-12 07:45:13 EDT
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 ?
Comment 5 udo 2012-09-14 11:14:00 EDT
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.
Comment 6 Lennart Poettering 2013-01-14 16:17:02 EST
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.
Comment 7 udo 2013-01-15 08:55:56 EST
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

Description=Multi-router Traffic Grapher

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 :
# - RunAsDaemon: yes; NoDetach: no :
# - RunAsDaemon: no; (periodic invocation) :

# 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.

Description=periodic invocation of MRTG


Comment 8 Fedora End Of Life 2013-01-16 12:42:37 EST
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: 
Comment 9 Lennart Poettering 2013-05-06 13:46:11 EDT
This is fixed in git/soon in F19.
Comment 10 Fedora Update System 2013-05-07 05:33:31 EDT
systemd-203-2.fc19 has been submitted as an update for Fedora 19.
Comment 11 Fedora Update System 2013-05-07 09:20:03 EDT
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
Comment 12 Fedora Update System 2013-05-07 09:45:19 EDT
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
Comment 13 Fedora Update System 2013-05-09 06:05:51 EDT
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:
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2013-05-15 23:01:51 EDT
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.

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