> > May I ask you devs to put a note on it into
> > http://man.openbsd.org/apmd.8
> > as there is currently no description of `apmd`
> > waiting for `/etc/apm/*` executables to finish
> > without processing new calls in the meantime.
>
> I don't see what to add, because it is obvious.
It's good such things are obvious to devs.
It's nice devs explain such things to non-dev users when asked.
For me it was quite a revelation that `apmd` and
> Almost all software of any kind does operations like this syncronously.
I personally have developed an impression that modern software
has shifted to being asynchronous wherever reasonable.
I would welcome such aspects mentioned to non-dev users
proactively in manpages.
Without this you are to expect more false bug reports from me :)
> > And may I ask you to also add hints on workarounds
> > like backgrounding (`apm &`) or running
> > yet another script, in background again, from `/etc/apm/*` scripts.
>
> That won't work.
Do we bear in mind the same thing?
Some other use cases may not work but why wouldn't mine?
`/etc/apm/resume`:
```
#! /bin/sh
{ [ "$(apm -av)" = 'A/C adapter state: connected' ] && anacron -s ;} &
```
I tried it and it works.
Same approach, rephrased:
a command sent to background continues running
after the script which issued the command has exited:
`/tmp/background`:
```
{ for i in $( jot 99 1 99 )
do
echo $i @ $(date) >> /tmp/background_output
sleep 0.1
done
} &
echo exit @ $(date) >> /tmp/background_output
exit
```
Run `sh /tmp/backgrounded` and maybe even quit the terminal
you issued the command from. The `/tmp/backgrounded_output`
will continue to be gradually echoed to.
Ultimately, this my scheme with `apm -a` and `anacron`
is for running `/etc/{daily,weekly,monthly}` maintenance
on a non-24/7 laptop.
https://www.unitedbsd.com/d/659-any-cons-against-anacronfcron-instead-of-cron
http://man.openbsd.org/daily#CAVEATS
> If the host machine is not running 24/7,
> these scripts may never be run.
> Adjusting the time fields in the system crontab(5)
> may partially alleviate this problem.
Which is obvious so no need for the caveat in the manpage,
yet I personally find it appropriate and
it really feels that devs actually care for users
by highlighting probable problems and how to tackle them.
