Am 12.02.2014 01:31 schrieb "Kai Krakow" <hurikha...@gmail.com>: > > Hey there! > Hey
> I've got a daily backup job scheduled using a timer unit and a oneshot > service file. This backup takes around 2-4 hours. It's using rsync and syncs > from btrfs HDD to a snapshotted btrfs on USB with inplace deltas. I'm > mentioning this because it may matter. > > I've also set my system to auto-sleep after 4 hours of idle time. This > means, in KDE I've set the option to put the system to sleep after that time > of inactivity. > > This usually works fine. But sometimes during backup, the system cannot > sleep. I see it still powered fully on the next morning. In dmesg, a lot of > btrfs and blockdev related tracebacks accumulated with notes of being unable > to sleep because a processed has refused to stop. I don't know if this is > btrfs-related or not - but actually I don't think it's wise to go to sleep > while the backup process is still running either. > > There may be a bug here, because almost every time when that happened it > looks like systemd has suspended my network connection but didn't bring it > back online after the system refused to go to sleep. I need to restart > NetworkManager then or reboot (I prefer reboot to alleviate any other side > effects that may have had). > > But what actually results from this is the following question: How do I > prevent systemd from trying to go to sleep while the backup job is running? > I'd like it to either (a) do not go to sleep at all (do not even try) or (b) > defer the sleeping signal until the backup job finished, with (b) preferred > plus some grace time. > > I don't know if something like "Conflicts=sleep.target" would do the job, I > even do not know if that would be a good idea at all. It's late here so excuse me if I'm missing something. But wouldn't a simple Before=sleep.target suffice to implement b)? If your backup job is still running it blocks sleep.target's start until it finishes. Though for the grace period some ugly hack such as "ExecStartPost=/usr/bin/sleep <n>" would be required. > Ah, and then another one, more or less unrelated: Lennart one time told me > that it's on the feature plan for systemd to wake the system up for selected > timer units and put it back to sleep afterwards. It would be a nice-to-have. > Still on the feature list? Maybe any news on that? I'd like to test it. > > Another one, partially unrelated: I've set up the backup mount point with > automount in systemd (via fstab). Is it possible to automatically undo that > automount upon finishing the backup job? If I explicitly call umount, the > job could wait forever if I accidently left a shell open in that directory. > This more or less concludes to the question: Could automount units also > automatically unmount after some idle time (after nothing any longer > accessed the volume)? > > -- > Replies to list only preferred
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
