Re: Switching Fedora machine away from systemd

[Denys Vlasenko]

On Fri, Apr 20, 2018 at 3:23 PM, Denys Vlasenko
 wrote:
>> What's missing or needs improvement?
>>
>> ifplugd_handler needs a better way to code for the "if service FOO exists,
>> start it, if it does not, it's fine" idiom.
>
> Surprisingly, there is no way to do this elegantly in a script.
>
> "test -d /var/service/DIR" depends on the fact
> that service dirs are in /var/service - which may be not true
> for some other daemontools-like installations. I don't like it.
>
> daemontools "svok SERVICE" (which now exists in current git,
> but not in 1.28.3) is better, but it emits an error message
> if SERVICE does not exist: it's defined to be silent only
> if supervisor is not running, not if service does not exist
> at all.
>
> I can just blindly run "svc -u/-d SERVICE" and ignore error
> messages. But how admin is to know that error is ok here?

A bit more brainstorming.


Another thing which needs some sort of agreement
among the distros:

How logging is specified?

As I see it, services fall into these categories
(with examples):

(a) Service wants to save a log, with reasonable size
(let's call it "default size as decided by the distro").
Say, ntpd: you want to have some history how it behaved
over time. Not something sadistically long, neither too short.

(b) Service wants to save a log, but it's not very important.
Say, gpm (mouse-handling thingy for VTs). I'm getting
about this much output each boot:
2018-04-24_07:05:00.75628 *** debug [daemon/add_mouse.c(50)]:
adding mouse device: /dev/input/mice
2018-04-24_07:05:00.75629 *** debug [daemon/add_mouse.c(98)]:
adding mouse type: ps2
2018-04-24_07:05:00.75629 *** debug [daemon/init_mice.c(39)]:
initialize /dev/input/mice with proto ps2
2018-04-24_07:05:00.75630 *** debug [daemon/init_mice.c(46)]:
finished initialization
2018-04-24_07:05:00.76843 *** debug
[daemon/get_console_size.c(45)]: Screen size: 80 - 25
2018-04-24_07:05:00.76844 *** debug
[daemon/get_console_size.c(62)]: x 10, y 20
2018-04-24_07:05:00.76845 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:05:00.76846 *** debug [daemon/getmousedata.c(60)]:
Error in protocol
2018-04-24_07:05:46.44039 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:05:52.49343 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:05:52.49348 *** debug [daemon/getmousedata.c(60)]:
Error in protocol
2018-04-24_07:06:12.05476 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:06:58.13655 *** debug [daemon/old_main.c(158)]:
selected 1 times
2018-04-24_07:06:58.13661 *** debug [daemon/getmousedata.c(60)]:
Error in protocol
2018-04-24_07:07:17.21047 *** debug [daemon/old_main.c(158)]:
selected 1 times
It is useful when/if I need to debug it, otherwise, saving e.g. 10
megabytes of such
"precious data" would be a waste of space.

(c) Service does not want to save any log. It will present errors elsewhere.
E.g. getty shows error messages on the tty it serves.

(d) Service usually does not want to save any log. If something goes wrong,
it'll exit with short (typically one-line) error message. Otherwise,
it'll present errors elsewhere. Example is the same: getty. In my current setup,
if getty service fails "catastrophically" (no tty), no messages
are emitted anywhere: stderr is redirected to >/dev/null.
It would be better to capture them.

IOW: we have two broad subclasses: services which want logging, and
services which
do not want it (but may benefit if their errors are channeled to a
single common log
of "not very talkative, not very important services").

As it stands now, for runit tools, services' stdout goes to wherever runsvdir's
stdout is directed (/dev/null in my case), stderr goes to runsvdir,
which in turn "rotates" it on its command line (which is visible in ps output).
This is a fairly limited in usefulness feature (one line of error visible, max),
and it can be disabled by deselecting FEATURE_RUNSVDIR_LOG.

Anyway, I digress a bit. My question is: how service should specify the desired
behavior, _in a distro-agnostic way_? Specifically:

(1) If you fall into the class of "not wanting to save the log",
currently I just don't have a log/ directory there. But I also use
exec >/dev/null 2>&1
at the beginning... because current way how runsvdir handles "non-logged"
services is stupid. Oh well, it's not that bad. Basically, it goes to /dev/null
(in my setup, with FEATURE_RUNSVDIR_LOG=n).
Probably should stop doing that redirect thing. But ideally, it should
be saved...
and distros should agree on this: "services are allowed to just use their
stdout/stderr for messages, if they don't have log/ service".

(2) Do not invoke "its author's favorite logging tool". Currently I use a
script which runs "svlogd -tt" under "logger" user. But what if distro
wants to use a different logging tool? Different user name? Etc?

Thus, I'm going with the following. All my services 

Re: Switching Fedora machine away from systemd

[Tim Tassonis]

On 04/20/2018 10:45 AM, Denys Vlasenko wrote:

On Fri, Apr 20, 2018 at 1:08 AM, Laurent Bercot  wrote:

Since no one had time/inspiration to create runit/daemontools
style servie supervision in Fedora, I'll going to create
something homegrown.


  I don't understand this.
  Why should there be a specific runit/daemontools style service
supervision *in Fedora* ?


I meant, there could be a package ready to be installed.
IIRC there is not.



  In the rest of your mail, it looks like you're trying to change the
*init system*.
  Yeah, right. Good luck with that. Getting a distro that has embraced
systemd to function right without systemd is a lost cause at this point.
Sure, you can always *boot* on your chosen init system. It's not hard.
The difficult part is the service management: if your chosen init
system is not natively supported by the distro, and in particular by
the package manager, it means you have to rewrite the way every
single daemon starts.


Sure.
The thing is, I don't need that many daemons.

In fact, one thing which was pissing me off is that there were like
3 times more daemons running than I needed. What is that
"systemd-logind" thing and since when login requires a _daemon_???
accounts-daemon? polkitd? rsyslogd? irqbalance? upowerd?
What _are_ all these programs and why they are in my memory?



  Then, even if you do that, further down the road, you'll find that
some packages don't work, because they're silently relying on an
obscure feature of systemd. And then it's headaches all the way down.

  Don't change the chosen init system of a distro without having support
from the distro itself. If you want to use your own process supervisor
instead of the distro's chosen supervisor, then do that - but run the
supervisor *on top of* the distro's init system. It will make your life
a lot simpler.



Running one of the much leaner and less intrusive init systems (let's 
call it again like that before systemd changed the language)? That 
sounds like putting a bicycle on top of a train to me.




But this will not allow me to have a webpage with a public description
how I eradicated canc^W systemd - and survived, no probs.
That would be so much less fun.


Thank you very much for this! I also had to un-systemd a Debian system 
for  as Rasperry Pi, which was a bit easier, as debian still provides an 
escape route from system. Otherwise I just switched away from systemd 
distros, but it is still a very good thing to show any Linux distro user 
any possible way out of the systemd trap.


Bye
Tim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Improve help for file type option in find

[Denys Vlasenko]

Applied, thanks!

On Mon, Apr 23, 2018 at 5:17 PM, Fred Friedrich  wrote:
> Instead of three dots show the user all possible file types (s for socket, p 
> for pipe)
>
> ---
>  findutils/find.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/findutils/find.c b/findutils/find.c
> index d9a42b3c6..07321c81a 100644
> --- a/findutils/find.c
> +++ b/findutils/find.c
> @@ -263,7 +263,7 @@
>  //usage: "\n-regex PATTERNMatch path to regex PATTERN"
>  //usage:)
>  //usage:IF_FEATURE_FIND_TYPE(
> -//usage: "\n-type XFile type is X (one of: f,d,l,b,c,...)"
> +//usage: "\n-type XFile type is X (one of: f,d,l,b,c,s,p)"
>  //usage:)
>  //usage:IF_FEATURE_FIND_PERM(
>  //usage: "\n-perm MASKAt least one mask bit (+MASK), all bits 
> (-MASK),"
> --
> 2.16.3
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox