~craftyguy

Oregon, US

Trackers

~craftyguy/superd

Last active 30 days ago

~craftyguy/caerbannog

Last active 1 year, 9 months ago

~craftyguy/ridecasa

Last active 2 years ago

~craftyguy/velotrack

Last active 3 years ago

#8 support starting dbus and services that use dbus 16 days ago

Comment by ~craftyguy on ~craftyguy/superd

On Fri, 18 Nov 2022 00:05:54 +0000 "~whynothugo" outgoing@sr.ht wrote:

I've experimented with a few apps unsetting the variable and that path just works. I still haven't unset it session wise to see what breaks.

Would you be interested in submitting a patch to set that path as the default if the var is unset when superd starts?

#8 support starting dbus and services that use dbus 17 days ago

Comment by ~craftyguy on ~craftyguy/superd

On Thu, 17 Nov 2022 23:48:02 +0000 "~whynothugo" outgoing@sr.ht wrote:

I've seen quite a few clients default to unix:path=$XDG_RUNTIME_DIR/bus if $DBUS_SESSION_BUS_ADDRESS is unset (Telegram / Qt comes, IIRC). It seems to be a standard thing, from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836117 :

In recent libdbus and GDBus, the fallback behaviour if DBUS_SESSION_BUS_ADDRESS is unset is to look for $XDG_RUNTIME_DIR/bus: if the environment variable is set, that directory contains ./bus, and ./bus is a socket owned by the current uid, then libdbus and GDBus will automatically use it.

Perhaps that would be the recommendable value here?

abstract socket is not a good idea; it's too easy to overlook when sandboxing (since it's not a regular socket/file).

Ah, thank you for pointing that out! I agree, it is a good idea to use that by default if the var is unset, especially if there is some precedence for other apps doing it too.

-Clayton

#38 crashed service does not auto-restart if it forked children 3 months ago

Comment by ~craftyguy on ~craftyguy/superd

fixed by a8136c3c

REPORTED RESOLVED FIXED

#38 crashed service does not auto-restart if it forked children 3 months ago

Comment by ~craftyguy on ~craftyguy/superd

I think this problem is due to this behavior in the Go runtime: https://go-review.googlesource.com/c/go/+/401835/11/src/os/exec/exec.go#247

// If WaitDelay is zero (the default), I/O pipes will be read until EOF,
// which might not occur until orphaned subprocesses of the command have
// also closed their descriptors for the pipes.

#38 crashed service does not auto-restart if it forked children 3 months ago

Comment by ~craftyguy on ~craftyguy/superd

I'll probably have to ditch go-cmd (or make a large patch for it...) to support calling Go's os/exec with an os.File, since that module only gives os/exec an io.Writer thing, which causes this whole issue.

#38 crashed service does not auto-restart if it forked children 3 months ago

bug added by ~craftyguy on ~craftyguy/superd

#38 crashed service does not auto-restart if it forked children 3 months ago

Ticket created by ~craftyguy on ~craftyguy/superd

reported by @stacyharper, this is actually the problem that I was trying to debug in #37. See my comments in that issue for more details.

go's os/exec doesn't consider the parent process to done (even if it crashes) since the stdout/stderr pipes are still open by any child process(es) it forks. One way to solve this is to send an os.File directly to exec to have service output written to separate files directly, instead of sending a pipe.

this can be reproduced by using the script from #37, and killing the parent process (the child should stay alive). superd will consider it still running.

#15 support parsing Environment= in service config 3 months ago

Comment by ~craftyguy on ~craftyguy/superd

Clayton Craft referenced this ticket in commit ea7a573.

REPORTED RESOLVED FIXED

#37 incorrect status when stopping a process that forks children 3 months ago

Comment by ~craftyguy on ~craftyguy/superd

Clayton Craft referenced this ticket in commit 63094e4.

REPORTED RESOLVED FIXED

#37 incorrect status when stopping a process that forks children 3 months ago

Comment by ~craftyguy on ~craftyguy/superd

This could be "solved" by writing service output directly to file(s), since Wait() does not block if stdout/stderr is an os.File. Which might not be a terrible idea, since splitting output from superd services into separate log files would make it easier to parse output from any particular service.