<div dir="ltr"><div><div><div><div><div>Hello,<br><br></div>it seems like 216 has a change that might affect this, namely giving OnCalendar-timers an implicit After-dependency on time-sync.target. (The changelog and most documentation says timeR-sync.target, but Debian's 215 at least doesn't have that.) Easy enough to add manually, but it would be nice if it were documented in README.Debian.<br><br></div>Then I'd get a few failures because backup.service would be started before the resume from suspend was actually complete (suspend.target and/or sleep.target still active), preventing systemd-inhibit from getting a wake-lock. Now I have After-deps on the suspend, sleep and hybrid-sleep targets as a workaround.<br><br></div>The band-aids seem to be holding, no missed backups for ~1 week.<br><br></div>Regards,<br></div>Christian Pernegger</div><div class="gmail_extra"><br><div class="gmail_quote">On 22 January 2016 at 10:39, Christian Pernegger <span dir="ltr"><<a href="mailto:pernegger@gmail.com" target="_blank">pernegger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Hello again,<br><br></div>I just wanted to document a few further observations & things I tried:<br><br></div>* A dummy timer that just sent me mail every hour (but otherwise configured identically) managed to wake the system up 20 out of 20 times and did send mail on 18 of these. Sadly, with the backup.service the track record is more like fifty-fifty.<br></div>* replacing ntpdate with systemd-timesyncd (the whole guarantees monotonic time thing) does not help<br><br></div>Status after a failed run:<br>chris@mrmackey:~$ sudo systemctl status backup.service<br>● backup.service - Pulls configured backups<br>   Loaded: loaded (/etc/systemd/system/backup.service; static)<br>   Active: inactive (dead)<br><br>chris@mrmackey:~$ sudo systemctl status backup.timer<br>● backup.timer - Wakes the system up once per day for backups<br>   Loaded: loaded (/etc/systemd/system/backup.timer; enabled)<br>   Active: active (waiting) since Don 2016-01-21 13:15:53 CET; 21h ago<br><br>chris@mrmackey:~$ sudo systemctl list-timers<br>NEXT                         LEFT     LAST                         PASSED  UNIT                         ACTIVATES<br>Sam 2016-01-23 03:00:00 CET  16h left n/a                          n/a     backup.timer                 backup.service<br>Sam 2016-01-23 10:06:21 CET  23h left Don 2016-01-21 13:30:30 CET  20h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service<br>[...]<br><br></div><div>Workarounds galore, of course, but I'd still prefer this function to work as documented.<br></div><br></div>Regards,<br></div>Christian Pernegger<div><div class="h5"><br><div><div><div><div><div><div><div><br><br><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 January 2016 at 10:36, Christian Pernegger <span dir="ltr"><<a href="mailto:pernegger@gmail.com" target="_blank">pernegger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Package: systemd<br>
Version: 215-17+deb8u2<br>
Severity: normal<br>
<br>
<br>
Hello,<br>
<br>
I'm trying to do the following:<br>
1) wake up the system every night at 3 am (using a timer unit with WakeSystem=yes)<br>
2) pull in backups (using a service triggered by the timer unit)<br>
3) send it to sleep again (via logind idle timeout)<br>
<br>
See attached files backup.timer and backup.service.<br>
<br>
Now, step 1 works, it'll always wake up at 3 am, and sometimes<br>
backup.service will then run as it should, sometimes it won't.<br>
<br>
(For completeness' sake: starting backup.service manually always<br>
works, as does running it on a timer when the machine is already<br>
up. Same goes for suspend on idle.)<br>
<br>
It might be some kind of timing issue but frankly I've no idea where<br>
to look. The journal doesn't show anything about the timer unit in any<br>
case, the service unit does get mentioned only because a sudo session<br>
is opened for it (only when it actually runs).<br>
<br>
Regards,<br>
Christian Pernegger<br>
<br>
<br>
<br>
-- Package-specific info:<br>
<br>
-- System Information:<br>
Debian Release: 8.2<br>
  APT prefers stable-updates<br>
  APT policy: (500, 'stable-updates'), (500, 'stable')<br>
Architecture: amd64 (x86_64)<br>
<br>
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)<br>
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)<br>
Shell: /bin/sh linked to /bin/dash<br>
Init: systemd (via /run/systemd/system)<br>
<br>
Versions of packages systemd depends on:<br>
ii  acl             2.2.52-2<br>
ii  adduser         3.113+nmu3<br>
ii  initscripts     2.88dsf-59<br>
ii  libacl1         2.2.52-2<br>
ii  libaudit1       1:2.4-1+b1<br>
ii  libblkid1       2.25.2-6<br>
ii  libc6           2.19-18+deb8u1<br>
ii  libcap2         1:2.24-8<br>
ii  libcap2-bin     1:2.24-8<br>
ii  libcryptsetup4  2:1.6.6-5<br>
ii  libgcrypt20     1.6.3-2<br>
ii  libkmod2        18-3<br>
ii  liblzma5        5.1.1alpha+20120614-2+b3<br>
ii  libpam0g        1.1.8-3.1<br>
ii  libselinux1     2.3-2<br>
ii  libsystemd0     215-17+deb8u2<br>
ii  mount           2.25.2-6<br>
ii  sysv-rc         2.88dsf-59<br>
ii  udev            215-17+deb8u2<br>
ii  util-linux      2.25.2-6<br>
<br>
Versions of packages systemd recommends:<br>
ii  dbus            1.8.20-0+deb8u1<br>
ii  libpam-systemd  215-17+deb8u2<br>
<br>
Versions of packages systemd suggests:<br>
pn  systemd-ui  <none><br>
<br>
-- Configuration Files:<br>
/etc/systemd/journald.conf changed:<br>
[Journal]<br>
Storage=persistent<br>
Compress=no<br>
<br>
/etc/systemd/logind.conf changed:<br>
[Login]<br>
IdleAction=suspend<br>
IdleActionSec=30min<br>
<br>
<br>
-- no debconf information<br>
</blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div>