prevent/pause cron jobs when on battery power

[networkimprov]

o.017 prevent/pause cron jobs when on battery power; resume on VBUS interrupt Also eliminate non-essential cron jobs Tony saw a filesystem maintenance job running during recent testing, using the ALARM stock rootfs, not our custom one

[thomasdziedzic]

We do not have cronie (supports cron on arch) installed on our rootfs.

[networkimprov]

Well are there periodic procedures we should consider running?

[thomasdziedzic]

I can't think of any currently.

I checked https://wiki.archlinux.org/index.php/General_recommendations which usually has some good recommendations. It doesn't seem like they mention anything related to cron.

@tmlind do you know what jobs get run on your board?

[networkimprov]

The ALARM rootfs might have some cron entries.

[networkimprov]

We'll probably want fstrim for NAND maintenance.

[thomasdziedzic]

rather than installing a cron daemon, I would like to utilize systemd's timers which should provide us with what we need and will allow us to avoid installing extra packages.

see https://github.com/networkimprov/omap3-usb-boot-install/commit/b209808c4bf63265f7c51e775becd6110e00f4e1

[thomasdziedzic]

With regards to how we are going to stop and resume background jobs, I found some good articles and programs which support such a use case:

http://www.robert.orzanna.de/simplistic-powersaving-with-systemd-service-files-and-udev-rules/ https://github.com/march-linux/powerdown https://github.com/supplantr/ftw

If you have any preference let me know, otherwise I will do some research and see which one I like.

[thomasdziedzic]

I just realized, since we want to run custom scripts when a power button is hit, and we want to run custom scripts on ac power and battery, why not just use the popular acpid?

It supports these use cases and we will just have to figure out what events get sent to acpid and what to run when those events fire.

I will have to disable the powerbutton in systemd, but that shouldn't be a problem since it's done through /etc/systemd/logind.conf

Adding this here for reference in the future since it shuts my anvl down currently :) Output of acpi_listen is:

button/power PBTN 00000080 00000000

[thomasdziedzic]

Adding link to acpid on the Arch Wiki for reference: https://wiki.archlinux.org/index.php/Acpid

[networkimprov]

ACPI is an x86-land standard, and I don't think OMAP kernels support it. It is being implemented for arm server platforms though.

@tmlind, any thoughts on Tom's comments/links above?

[tmlind]

Sounds like It would be best to not get stuck with acpid like we did with apm emulation layer on ARM :) Using udev events + systemd + custom scripts is probably the best way to go. I think we need the systemd in this case mostly for logging things.

[networkimprov]

Tom, I'd be interested to hear your analysis of the possible udev-based schemes, and which seems best for our stack.

[thomasdziedzic]

So in order to handle events on power status change, I think we should write udev rules along the lines of: https://github.com/march-linux/powerdown/blob/master/powerdown.rules

For the powerbutton, if we do not want to sleep, hibernate, poweroff, then we might have to use acpid to detect when the powerbutton has been pressed in order to run custom scripts. acpid does handle acpi events, but it also handles device inputs, from man acpid:

FILES
       /proc/acpi/event
       /dev/input/event*

[networkimprov]

We've been discussing the on/off switch here: https://github.com/networkimprov/arch-packages/issues/11 Have you found udev rules for battery charging/draining?

[networkimprov]

Oop, those are indeed rules for battery charging/draining... Does this work correctly for going to sleep while on battery power, then waking due to usb connect?

[thomasdziedzic]

Since the power button is supposed to suspend, I'm not sure if connecting the anvl to a usb power supply will unsuspend it. I would think that you would have to press the switch again.

Unfortunately I don't have a battery to test against.

[networkimprov]

The PMIC can make that happen, if it doesn't already. @tmlind?

[tmlind]

We wake to pretty much all the interrupts unless they are manually disabled for the irqwake via the driver's sysfs entry with echo disabled > wakeup.

[networkimprov]

Tom, can you cook something up to start fstrim on usb-connect and stop it on usb-disconnect? Also we need to work out the interval between complete passes.

Tony can test it for both cases: USB out-in, and out-suspend-in.

[thomasdziedzic]

I added a udev rule which will start/stop the fstrim.timer when charging/discharging:

https://github.com/networkimprov/arch-packages/blob/master/archlinux-anvl/anvl-usb/70-charging-discharging.rules

Please let me know what you find from your testing

[thomasdziedzic]

oh, to actually install the script, all you need to do is run pacman -Syu on your anvl to install the latest anvl-usb package.

[thomasdziedzic]

Just made a minor fix to anvl-usb. Apparently run-parts needs the magic header to execute scripts.

[networkimprov]

Why different names for the srcdir and pkgdir files?

[thomasdziedzic]

If you're referring to installing fstrim-charging into charging.d then that works because if the target is an exising folder, it installs the source into that folder.

[tmlind]

Hmm I think fstrim should only be run at most once per week when charging? So some state checking may be needed, I don't think fstrim does that.

[thomasdziedzic]

I think it should be fine, this is where systemd provides some pretty awesome functionality:

cat /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=multi-user.target

[networkimprov]

So why the separate install -d to create the directory, vs install -D -m ... for the files?

[thomasdziedzic]

I did install -d since I wanted to create the folder in anticipation that there will be more files added to the pkgbuild other than fstrim. This has the benefit of avoiding to having to retype the file we're installing each time and we don't need to create the charging.d/discharging.d folders each time we want to install a file.

[tmlind]

OK cool :)

[networkimprov]

anvl-usb has become a catchall package, so maybe we should rename it anvl-util and merge omap-idle into it.

[thomasdziedzic]

1. updated libusbg-git because there are a lot of changes that got merged including Tony's patch: https://github.com/libusbg/libusbg
2. merged anvl-usb and omap-idle into anvl-util
3. fixed rootfs creation script as a result of the rename

[tmlind]

OK sounds good to me :)

[networkimprov]

What about mandb, which is in base? It runs background processes to update its index.

[thomasdziedzic]

These are the timers that are installed on the default system:

[self@anvl ~]$ systemctl list-timers 
NEXT                         LEFT        LAST                         PASSED       UNIT                         ACTIVATES
Fri 2014-10-24 03:12:35 UTC  9min left   n/a                          n/a          systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sat 2014-10-25 00:00:00 UTC  20h left    Fri 2014-10-24 02:58:30 UTC  4min 14s ago logrotate.timer              logrotate.service
Sat 2014-10-25 00:00:00 UTC  20h left    Fri 2014-10-24 02:58:30 UTC  4min 14s ago man-db.timer                 man-db.service
Sat 2014-10-25 00:00:00 UTC  20h left    Fri 2014-10-24 02:58:30 UTC  4min 14s ago shadow.timer                 shadow.service
Mon 2014-10-27 00:00:00 UTC  2 days left Mon 2014-10-20 02:40:40 UTC  4 days ago   fstrim.timer                 fstrim.service

5 timers listed.
Pass --all to see loaded but inactive timers, too.

I think we can disable all of the timers on battery power. Thoughts?

[thomasdziedzic]

Thoughts on my previous comment?

[networkimprov]

Yes, let's disable all timers on battery power. @tmlind, comments?

[tmlind]

Yes makes sense to me from PM point of view.

[thomasdziedzic]

I added the rest of the timers. I think we can close this issue since it solves the original issue correct?

[networkimprov]

Do the other timers work like fstrim, meaning on systemctl start, systemd will start the associated programs if the timer has elapsed during the stopped period?

[thomasdziedzic]

The only timer that does not have it is: systemd-tmpfiles-clean.timer I don't expect there to be any issues though since we should not be using that many (any?) temporary files while on battery.

[networkimprov]

Many packages create tmp files, and configure systemd-tmpfiles to clean them up. I think we would rather not run this timer when on battery.

[thomasdziedzic]

systemd-tmpfiles-clean.timer is disabled on battery and enabled on charge.

Is there anything left in this ticket? I believe all timers are now disabled.

[networkimprov]

I didn't see a commit?

[thomasdziedzic]

https://github.com/networkimprov/arch-packages/commit/e84af10c7ad4cd48622f9dd152f0632eb863adc5

[networkimprov]

Erm, you said systemd-tmpfiles-clean wasn't configured like fstrim, to start the procedure if the timer elapsed during a battery-powered period..?

[thomasdziedzic]

Ah right.

[thomasdziedzic]

So if we want to make that happen, we can either do a drop in overwrite with the installer, a package, or maintain a separate systemd. The last one is probably not a good choice. Any preference?

[thomasdziedzic]

Lowest effort would probably be the installer option.

[networkimprov]

Seems like you could add the relevant files to package anvl-util?