Oregon, US
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
Comment by ~craftyguy on ~craftyguy/superd
On Wed, 15 Feb 2023 09:28:09 +0000 "~whynothugo" outgoing@sr.ht wrote:
A change (compared the the current implementation) is that is uses a directory for each service. I don't think that's a huge deal tho.
Ah I see, so a single instance of s6-log per service. I guess that's fine, the binary probably isn't that large and having N copies running for N services probably isn't too bad.
A weirdness might be the dependency on s6-log, which ships as part of s6. If you feel it's a very weird fit, it can at least serve as inspiration/reference. In particular, I like the fact that it's a separate reusable binary of its own and its strong focus on both not losing logs, but also not filing up disk.
That is a bit weird, yes... Especially for other distros that might package/use superd (I'm not sure if they're out there, but ???. heh.) This could be solved by making some logger interface in superd that could use multiple backends, and it could use s6-log if that's available, else fall back to the current thing (just an idea, maybe could be improved on further)
Comment by ~craftyguy on ~craftyguy/superd
this does seem pretty nice! I'm not quite sure how this could be used by superd, since we probably still want service output logged to separate files, and the list of services can change dynamically at runtime (as services are started/stopped/added to superd). Do you have any ideas on how this could be used?
enhancement added by ~craftyguy on ~craftyguy/superd
Comment by ~craftyguy on ~emersion/grim
I see, thank you for the redirection!