Hi,
I am running version 216. I will try to reproduce it using a newer version when
I got some spare time.
I tried to reproduce it and I had, at first, some problems. But here are the
steps that I used:
* Enable autobackup@merten.timer
* Restart system with AC connected
* Let the timer activate once
* Disconnect AC
* Wait for next timer trigger
After the timer elapsed the dbus-daemon fully utilizes the CPU with messages
like the following:
signal sender=:1.0 -> dest=(null destination) serial=5611797
path=/org/freedesktop/systemd1/unit/autobackup_40merten_2etimer;
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.systemd1.Timer"
array [
dict entry(
string "NextElapseUSecRealtime"
variant uint64 0
)
dict entry(
string "NextElapseUSecMonotonic"
variant uint64 1671969806
)
dict entry(
string "LastTriggerUSec"
variant uint64 1432119664109599
)
dict entry(
string "LastTriggerUSecMonotonic"
variant uint64 1820165195
)
dict entry(
string "Result"
variant string "success"
)
]
array [
string "TimersMonotonic"
string "TimersCalendar"
]
Attached you find the service and timer units that I used.
Thanks
On 19/05/15 16:57, Lennart Poettering wrote:
> On Thu, 02.04.15 12:01, Merten Sach (mer...@tabinin.eu) wrote:
>
>> Hi,
>>
>> I have a problem with a timer that trigges a service that has a condition
>> set.
>> The timer defines the following properties:
>>
>> [Timer]
>> OnBootSec=1h
>> OnUnitInactiveSec=1h
>> Unit=autobackup@%i.service
>>
>> The service unit set the following condition:
>>
>> ConditionACPower=true
>>
>> When I'm now on AC power the service is never active and, therefor, the
>> inactive
>> timestamp is never set. This causes the timer to be triggered repeatedly
>> which
>> causes a very high system load.
>>
>> I want to keep the timer relative to bootup. So, can I avoid OnCalendar= ?
>
> Hmm, so I tried to reproduce this issue here, bu I couldn't. I used
> the same unit files as you propose, but this works cleanly, as the
> code already contains checks that if the triggered unit doesn't have
> an initialized inactive timestamp we'll fall back to the last trigger
> time of the unit. And if that's not set, we'll simply not set any
> timer...
>
> Hence, which version of systemd did you run this into with?
>
> Any chance you can check if you can reproduce this with current git or
> at least 219?
>
> Lennart
>
[Unit]
Description=autobackup service
Documentation=
Wants=avahi-daemon.socket
ConditionACPower=true
[Service]
Type=simple
User=%i
ExecStart=/usr/bin/true
#ExecStart=/usr/local/bin/autobackup
[Unit]
Description=autobackup timer
Documentation=
[Timer]
OnBootSec=3m
OnUnitInactiveSec=3m
Unit=autobackup@%i.service
[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
