Oregon, US
Comment by ~craftyguy on ~martijnbraam/logbookd
Ugh, I just discovered
logbookd -g, sorry for the noise. I can't edit this todo(??!) but I think it would still be nice to have a way for entries in memory (when using-r) to be rotated to disk instead of being dropped entirely. Is this possible?
Ticket created by ~craftyguy on ~martijnbraam/logbookd
With logbookd, a user can (I did this!) spam writes to syslog until the system memory is full. The OOM killer might end up killing logbookd to free memory.
For a good init system, this isn't too bad since logbookd will probably be restarted. You may lose log data though (e.g. if run with
-r).On systems with limited init systems, logbookd may not be restarted. In that case, a normal user was effectively allowed to disable all system logging for the current boot by causing logbookd to get OOM killed, and I don't think that's good...
Is there some way to limit the amount of data in memory?
When rotating entries in memory, it could dump old ones to disk (e.g.
-r?I think a hard limit of 10% of system RAM, where entries in memory would be rotated so it doesn't continue to grow unbounded, would be sufficient even for devices (N900) with <1GB memory... it seems unlikely the in-memory log data would approach hundreds of MB?
Ticket created by ~craftyguy on ~martijnbraam/logbookd
The database saved to disk shouldn't be allowed to grow indefinitely, so there should be some automatic log rotation to prevent this from happening. Traditionally for text file-based logging,
logrotateis used to do this.Having a way to specify some conditions for when the rotation happens could be nice, e.g., force rotation of size of logs on disk is greater than 100MB or something. It could be user-configurable, maybe through an ENV var?
Ticket created by ~craftyguy on ~martijnbraam/logbookd
One use case for logbookd is to run it as a system service with
-r, where it will write the db to disk when it it receives SIGTERM. One situation where it can receive SIGTERM is on shutdown or reboot, from the system's init. It would be bad if logbookd ended up filling the rest of the rootfs to 100% when the system was powering off or rebooting, it probably won't boot correctly again.Maybe there should be some way to guard against this. I suggested only writing if the number of free bytes on the filesystem was larger than the number of bytes to write out, but it was pointed out that this isn't trivial to do in sqlite3 and C.
Also see: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4549#note_1683443994
Comment by ~craftyguy on ~craftyguy/superd
On Thu, 27 Jul 2023 07:05:19 +0000 "~whynothugo" outgoing@sr.ht wrote:
I can't figure out why, but
xdg-desktop-portalwon't auto-start:> superctl status xdg-desktop-portal xdg-desktop-portal Status: stopped Type: simple PID: - Uptime: - Autostart: ✓ Loaded: /home/hugo/.config/services/enabled/xdg-desktop-portal.service Description: Desktop integration portals for sandboxed apps > superctl status Status PID Autostart blueman-applet started 4536 ✓ calls stopped - - chatty stopped - - darkman started 4532 ✓ display_switch stopped - - dockerd-rootless started 4531 ✓ fnott stopped - - foot stopped - - gammastep stopped - - himitsud started 4530 ✓ kanshi stopped - - librespot-himitsu stopped - - libvirtd started 4537 ✓ light stopped - - mako started 4535 ✓ mmsd-tng stopped - - mpris-proxy stopped - - pipewire started 4529 ✓ pipewire-pulse started 4758 ✓ ra-multiplex-server started 4540 ✓ swayidle stopped - - udiskie stopped - - vvmd stopped - - waybar stopped - - wireplumber started 4760 ✓ wob stopped - - wys stopped - - xdg-desktop-portal started 6035 ✓Hmm... interesting how this status conflicts with the one above that shows "stopped"...
xdg-desktop-portal-wlr started 4759 ✓
yubikey-touch-detector started 4538 ✓Looking at the logs, it seems that there wasn't even at attempt to start it:The superd log should show whether or not it tried to start it.
Comment by ~craftyguy on ~craftyguy/superd
fixed by 75cd01e
REPORTED RESOLVED FIXED
bug added by ~craftyguy on ~craftyguy/superd
Ticket created by ~craftyguy on ~craftyguy/superd
Reported by triallax in chat . It only prints the status for the first given service, when it should be printing the statuses for all given services:
$ superctl status light udiskie fnott light Status: started Type: oneshot PID: - Uptime: - Autostart: ✓ Loaded: /home/clayton/.config/services/enabled/light.service Description: Restore saved backlight brightness level $
Comment by ~craftyguy on ~craftyguy/superd
On Mon, 27 Feb 2023 22:55:25 +0000 "~timsofteng" outgoing@sr.ht wrote:
Hello. How should I properly run mpd with pipewire backend in tty with superd and without gui?
How do mpd and pipewire communicate? If it's through dbus, then you'll need to make sure both superd and mpd have the same dbus session address set (there's an environment variable for it.)
Comment by ~craftyguy on ~craftyguy/superd
On Wed, 15 Feb 2023 18:41:53 +0000 "~aren" outgoing@sr.ht wrote:
Systemctl has an is-active subcommand which is useful in scripts that need to check the status of a service
I think this would be really helpful, thanks for the suggestion!
From the systemctl docs:
Check whether any of the specified units are active (i.e. running). Returns an exit code 0 if at least one is active, or non-zero otherwise. Unless --quiet is specified, this will also print the current unit state to standard output.
If I understand that correctly, it should do something like this?
$ superctl is-active foo stopped $ echo $? 1 $ superctl start foo $ superctl is-active --quiet foo $ echo $? 0