Firstly, the `ps auxw | grep apm` output got automatically distorted.
Here is a manually word wrapped version, for clarity:
root 53666 0.0 0.0 196 328 ?? IU Wed09PM 0:00.33 \
/usr/sbin/apmd -A -t 60 -z 15
root 40604 0.0 0.0 1004 916 ?? Ip 7:42PM 0:00.01 \
/bin/sh /etc/apm/resume
root 64804 0.0 0.0 184 752 ?? Ip 7:42PM 0:00.01 \
apm -av
root 33185 0.0 0.0 996 944 ?? Ip 1:30AM 0:00.01 \
/bin/sh -c [ "$(apm -av)" = 'A/C adapter state: connected' ] && \
anacron -s
root 37775 0.0 0.0 172 880 ?? Ip 1:30AM 0:00.00 \
apm -av
root 33407 0.0 0.0 640 1604 pb S+p 5:38AM 0:00.01 \
grep apm
Hello, Raf
Thanks for the points you made.
It is nice here are such attentive and caring people.
>> Laptop is being powered via A/C via dockstation; battery is pulled out.
>> apmd_flags=-A -t 60 -z 15
> On a system without a battery, using '-z' is nonsensical and '-t'
> is redundant as, without the battery, the power state will never
> change... unless, of course, you unplug the power in which case
> none of it will matter anyway ;^)
The laptop is generally A/C powered,
and for occasional battery-poweredness I want it to be
hassle-free by having been already configured.
> root's PATH does contain /usr/local/sbin, however crontab's PATH, does not.
> You'll either have to use the full path - /usr/local/sbin/anacron
> - or adjust PATH accordingly.
My omission
>> @daily 0 id_daily /bin/sh /etc/daily
>> @weekly 0 id_weekly /bin/sh /etc/weekly
>> @monthly 0 id_monthly /bin/sh /etc/monthly
> anacrontab(5) from this port doesn't supports @-strings known from
> crontab(5) or 3rd-party updates to anacron(8).
Nice you stressed it.
I took the @-strings from examples across the internet.
Although neither
`man anacrontab` nor `/usr/local/share/doc/pkg-readmes/anacron`
say about supporting @-strings,
they don't make it explicit that @-strings are not supported
in this particular port
unlike `anacron` configurations you may encounter elsewhere.
>> so additional quotes are probably required like this:
>> /bin/sh -c '[ "$(apm -av)" = 'A/C adapter state: connected' ] && anacron -s'
>>
> You can't use (') quotes inside (') quotes without escaping them first.
My confusion. Thank you.
But I'd rephrase it as single quotes are not nestable.
Unless backslashed, a single quote starts a strong quoting.
Next single quote ends the strong quoting,
regardless of having backslash before it.
>> sd1 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006>
>> sd1: 476937MB, 512 bytes/sector, 976767473 sectors
>> root on sd1a (942f936162d34584.a) swap on sd1b dump on sd1b
> you're using SoftRAID. Have you allocated disk space the
> standard/automatic way? Is your swap space large enough[0]?
Allocated manually, 24G swap, 16G RAM.
Correlation from RedHat Linux recommendations.
In the thread you linked, there is a post
https://marc.info/?l=openbsd-bugs&m=164226571307343&w=2
with different numbers:
> The payload is compressed RLE of in-use memory,
> after discarding cached memory. It is not a 1:1 copy of physical
> memory. Upon resume, you see the number. It tends to be way less than
> 1/4 of memory, but it is hard to say.
>> acpi0 at bios0: ACPI 5.0
>> acpi0: sleep states S0 S3 S4 S5
> BTW, it your laptop's BIOS supports it so, normally, it shouldn't
> be a problem to hibernate.
I had been successfully hibernating and suspending
until all this ugly misconfiguration.
However, it once kinda hung at the end of hibernation,
the screen was already black,
disk activity LED light was blinking for too long,
and I just powered it down.
On the next boot, my desktop session was restored completely fine.
Dunno.
But, despite my configuration blunder, in my opinion
`apm` behaves in an unexpected and undesired way.
My misconfiguration may be bad enough to serve its purpose
but it is good enough to run the `apm`.
It is present at the `ps` output, so it got launched.
`apm -av` shows in `ps` for indefinitely long time,
although it makes a single instant action.
Maybe it waits for my command to receive its output,
which doesn't happen?
But new `apm` commands hang!
Can `apm` handle several requests simultaneously
or needs it to release a previous call
in order to be able to serve the next one?
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
So a badly written script or one made bad on purpose
blocks subsequent calls to `apm`. It shouldn't happen.
If I misunderstand something, please clarify.
Just after a reboot:
> ps auxw | grep apm # manually word wrapped
root 64545 0.0 0.0 196 824 ?? IU 8:51PM 0:00.00 \
/usr/sbin/apmd -A -t 60 -z 15
root 34093 0.0 0.0 1004 944 ?? Ip 8:51PM 0:00.00 \
/bin/sh /etc/apm/powerup
root 60501 0.0 0.0 180 944 ?? Ip 8:51PM 0:00.00 \
apm -av
v11e 41126 0.0 0.0 636 1628 p1 S+p 8:57PM 0:00.01 \
grep apm
and again `apm` not responding.
`kill -15` has no effect on `/bin/sh /etc/apm/powerup`
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
`kill -15` on `apm -av` or
`kill -9` on `/bin/sh /etc/apm/powerup` also take down
`/usr/sbin/apmd -A -t 60 -z 15`:
# ps auxw | grep apm # manually word wrapped
root 63317 0.0 0.0 632 1624 p1 S+p 8:59PM 0:00.01 \
grep apm
# rcctl check apmd
apmd(failed)
It shouldn't happen, should it?!
BTW, on OpenBSD what tool should I use for monitoring important daemons
or other long-running commands that would
restart them in case of their crash etc.?
Is there something in base? Is it planned?
Is there a de-facto standard or relatively standard
third-party package for the task?
`sysutils/dinit`? `sysutils/perp`? `sysutils/supervisor`?
`rcctl restart apmd` entails `/bin/sh /etc/apm/powerup`:
# ps auxw | grep apm # manually word wrapped
root 8833 0.0 0.0 192 856 ?? SU 9:41PM 0:00.00 \
/usr/sbin/apmd -A -t 60 -z 15
root 48498 0.0 0.0 1012 1000 ?? Sp 9:41PM 0:00.00 \
/bin/sh /etc/apm/powerup
root 81734 0.0 0.0 188 984 ?? Sp 9:41PM 0:00.00 \
apm -av
root 24840 0.0 0.0 632 1624 p1 S+p 9:41PM 0:00.01 \
grep apm
I wouldn't expect `/bin/sh /etc/apm/powerup` to appear here as
this is not a powerup, it is a launching of the `apmd` on a machine
that has been powerupped for a while. These are separate cases.
Recap:
0. My setup is misconfigured, that is up to me,
but IMHO it has revealed 3 `apm` problems:
1. a badly written command or one made bad on purpose
blocks subsequent `apm` operations
yet `apm` should respond reliably
2. `kill`ing `/bin/sh /etc/apm/powerup`
or `apm -av` invoked by the former
also kills `apmd`
yet it should remain intact
3. starting `apmd` on an already running machine
is not distinguished from machine powerup
and executes `/etc/apm/powerup`
yet it is not a powerup
