Closed aksh1618 closed 5 years ago
It was a deliberate design decision to not background the clipster
daemon. The command-line flag simply refers to the 2 operating modes - daemon
and client
- of which client
is the default.
There are a ton of ways to manage daemons in the background 'properly' these days - sysvinit
, systemd
, daemonize
, start-stop-daemon
, service
, a variety of DE background tasks
and session managers, bash
&`etc etc.
Implementing background daemons in clipster
would add extra code with no real benefit. Additionally, this would also require the addition of a --foreground
flag for those who don't want to daemonise, and this would need to be the default behaviour in order to not break functionality for those already using it with other process management strategies. (So effectively the whole change would be a noop
for most people).
There is potentially an argument that can be run as a background task
is ambiguous, but given the long list of alternatives above, I didn't want to prescribe (and then have to document and support) any one of them over the other.
Hopefully this explains the current design implementation!
Yes, it does :) It's just that daemon
option in my mind makes me think run in background
, but maybe that's just me.
In any case, maybe add a note/warning that using --daemon
doesn't make it run in background, thereby avoiding specifying a way to run in background?
When I run
I expect it to run in background, but it instead runs in foreground, leading to system freeze when used in
.xinitrc
.The README also doesn't suggest the use of
and
isn't clear enough IMHO. Regardless, I believe anyone using
--daemon
would expect the program to daemonize and run in background, not hold the thread.