Re: Switching Fedora machine away from systemd

[Denys Vlasenko]

On Fri, Apr 20, 2018 at 2:33 PM, Natanael Copa  wrote:
> On Thu, 19 Apr 2018 17:18:29 +0200
> Denys Vlasenko  wrote:
>
>> After yet another incident of wandering among endless
>> directories/"targets"/links trying to figure out how to stop
>> the laptop from falling asleep on lid close, I've had enough.
>>
>> Since no one had time/inspiration to create runit/daemontools
>> style service supervision in Fedora, I'll going to create
>> something homegrown.
>>
>> This also doubles as a test whether busybox's runit tools
>> are up to the task.
>
> Or you could use Alpine Linux which uses busybox and musl libc out of
> the box, and with openrc instead of systemd.

I frequently need to work on Red Hat-related problems.
Using Fedora in such case is far less hassle.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

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: Switching Fedora machine away from systemd

[Denys Vlasenko]

>Hmm. A tool to wait for a file is needed. So far this should do - /bin/need:
>
>#!/bin/sh
>i=0
>while ! test -e "$1"; do
>sleep "0.$i"
>test "$i" = 9 || i=$((i+1))
>done

Surely, this already exists? Anyone knows?


> Created /var/service/dbus-daemon service. run file:
>
> #!/bin/sh
> #exec >/dev/null
> exec 2>&1
> exec  test "`pidof systemd`" && exec sv d .

This is not entirely correct: "sv d" may exit before "down"
signal is acted upon by supervisor. Thus, the service may be
restarted yet another time.
It's mostly harmless since even if it would be, then it'll be stopped.
But this can be avoided using: && sv d . && exec sleep 1

Also, I'm going to switch to using "svc" instead of "sv"
in all service scripts. This way, they will be compatible
with original daemontools. (Since there are several competing
daemontools derivatives, we need to give people a chance
to write service scripts which run on any of them, unmodified.
Without ugly conditionals.
For one, they need either "sv" or "svc" to always work.
I vote for "svc" - the original author's name.)


> Created /init script.
> #!/bin/sh
> export PATH=/sbin:/bin:/usr/sbin:/usr/bin
> /etc/runit/1
> exec 0>&- 1>&- 2>&-
> # In this form, shell won't have an open fd to the script file
> exec env - sh -c 'while :; do sleep ; done'
>
> Isn't it a cutie.

Cheeky. But we probably need to have a binary which loops
on waitpid(-1), not the shell. For one, it'll be smaller. Two,
no need to have that sleep process. Third, actually, ":"
in some shells _may fail_ (e.g. if received SIGINT.

Anyone knows something existing and already suitable?
If not, what name would you prefer?

> Reboot/poweroff does not need cooperation with init.
>
> [todo: write it up here]

Copied examples/shutdown-1.0 to /app/shutdown-1.0.
Installed /sbin/* symlinks as described in README.

https://git.busybox.net/busybox/tree/examples/shutdown-1.0/README


> 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?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Tito]

On 20/04/2018 10:45, 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.

Hi,
this is still possible even with debian 9 as I have 2 routers
and 2 servers which run fine without systemd.
On my laptops I use Devuan + XFCE.
All of them do work as expected.
If you like RPM based distros try PCLinuxOS.

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

I do...and they work with no hassle.
Had to write just 1 or 2 init scripts (evebox and one for
a service that feeds info to the lcdproc daemon for the router's
LCD)

 2238 ?S  0:52 /usr/sbin/ifplugd -i eth0 -q -f -u0 -d10 -w -I
 2239 ?Ss 4:39 /usr/sbin/vnstatd -d --pidfile /run/vnstat/vnstat.pid
 2314 ?Ss 0:00 /sbin/mdadm --monitor --pid-file 
/run/mdadm/monitor.pid --daemonise --scan --syslog
 2339 ?S 24:47 /usr/sbin/LCDd -s 1 -f -c /etc/LCDd.conf
 2377 ?Ss 1:12 /usr/sbin/haveged -w 1024
 2406 ?S  0:55 /usr/sbin/arpwatch -i eth1 -f eth1.dat -m root -u 
arpwatch -N -p
 2411 ?S  0:01 /usr/sbin/arpwatch -i br0 -f br0.dat -m root -u 
arpwatch -N -p
 2432 ?Ssl  374:10 /usr/bin/suricata -c /etc/suricata/suricata.yaml 
--pidfile /var/run/suricata.pid -q 0 -D
 2512 ?S  4:47 /usr/sbin/ifplugd -i eth1 -q -f -u0 -d10 -w -I
 2576 ?Ss 5:32 /usr/bin/lcdexec -s 1 -c /etc/lcdexec.conf
 2603 ?Ss 0:00 /lib/startpar/startpar -f -- lcdexec
 2735 ?Ss 0:13 /usr/sbin/cron
 2760 ?S  0:01 /usr/sbin/smartd --pidfile /var/run/smartd.pid
 3111 ?Sl   368:12 /usr/bin/evebox --config /etc/evebox/evebox.yaml 
--datastore sqlite --input /var/log/suricata
 9203 ?Ssl0:52 /usr/sbin/rsyslogd
 9578 ?Ss 0:00 /sbin/dhclient -4 -v -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0.leases -I -df
 9620 ?S 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.

Packages have dependencies and so you'll find out rather soon.

>>   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.
> 
> 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.

Yes a lot of fun and a lot to learn.
Could it be done? You'll not know if you don't try yourself.

"Provando e riprovando."
(Dante, Paradiso, c. III, v. 3).

Ciao,
Tito
 
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Philip Rhoades]

Denys,


On 2018-04-20 18:47, Denys Vlasenko wrote:
On Thu, Apr 19, 2018 at 10:38 PM, Philip Rhoades  
wrote:

Denys,

As a long-time Fedora (mostly) user I found this very interesting!


Which part?



All of it!  You have done a lot of work so far - I guess my prime 
interest would be creating a minimalist Fedora ex systemd and with 
busybox - it would be good for my old machines - I have quite a 
collection of them and it is convenient to be able to have distro 
consistency.  I am just about to test out one of the old boxes with a 
floppy-booted distro - but I think that is probably not possible for 
Fedora . .


P.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Natanael Copa]

On Thu, 19 Apr 2018 17:18:29 +0200
Denys Vlasenko  wrote:

> After yet another incident of wandering among endless
> directories/"targets"/links trying to figure out how to stop
> the laptop from falling asleep on lid close, I've had enough.
> 
> Since no one had time/inspiration to create runit/daemontools
> style servie supervision in Fedora, I'll going to create
> something homegrown.
> 
> This also doubles as a test whether busybox's runit tools
> are up to the task.

Or you could use Alpine Linux which uses busybox and musl libc out of
the box, and with openrc instead of systemd.

-nc
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Denys Vlasenko]

On Thu, Apr 19, 2018 at 10:38 PM, Philip Rhoades  wrote:
> Denys,
>
> As a long-time Fedora (mostly) user I found this very interesting!

Which part?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Denys Vlasenko]

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.

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.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Philip Rhoades]

Denys,

As a long-time Fedora (mostly) user I found this very interesting!

Thanks!

Phil.


On 2018-04-20 01:18, Denys Vlasenko wrote:

After yet another incident of wandering among endless
directories/"targets"/links trying to figure out how to stop
the laptop from falling asleep on lid close, I've had enough.

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

This also doubles as a test whether busybox's runit tools
are up to the task.

https://busybox.net/ -> [Life without systemd]


Runit tools in busybox - up to the task?

Let's test busybox's runit applets in a hypothetical ;) scenario
when someone needs to stop running, say, systemd on, say, a Fedora 
machine.


No doubt this will expose various shortcomings.

Started with the machine configured and running under systemd.
Machine has xfce4 desktop environment installed.

Created /var/service and copied busybox/examples/var_service/* there.

Renamed/copied getty_tty1 to getty_tty9/10/11/12 (these consoles are 
not used

by existing setup).

Deleted dhcpd_if, ftpd, httpd, inetd, nmeter, tftpd (hmm, this needs a 
way

to store inactive services somewhere in a separate directory).

Adjusted fw/run (need more configurable way to do it; lacks a way to 
specify

more than one "external" (firewalled) interface).

Renamed/copied dhcp_if, dhcp_if_pinger, ifplugd_if each to a pair
of services for eth0 and wlan0.
Renamed supplicant_if only for wlan0.
Renamed zcip_if only for eth0 (how exactly zeroconf supposed to coexist
on more than one iface? They would all have 169.254/16 subnet - ?!).

Created a user to save all logs under:
groupadd -f --system logger
useradd --system -g logger -d /tmp -s /bin/false logger

Created /var/service/start:

#!/bin/sh
dir=/var/service
export PATH=/sbin:/bin:/usr/sbin:/usr/bin
exec /dev/null 2>&1
umask 022
cd "$dir" || exit $?
exec env - PATH="$PATH" runsvdir -P "$dir"

Created /etc/systemd/system/var.service:

[Unit]
Description=/var/service support
[Service]
ExecStart=/var/service/start

Added symlink: /etc/systemd/system/multi-user.target.wants/var.service 
->

-> /etc/systemd/system/var.service

Deinstalled NetworkManager.

Rebooted and tested that services from /var/service do start, and 
nicely

coexist with the rest of the system.

Tested network (DHCP, zeroconf) and local DNS caching to work.

Now we will pry off X startup from systemd.

Changed /etc/systemd/system/default.target symlink to point to
/lib/systemd/system/multi-user.target instead of a GUI link.
Reboot. Now the system should start with Linux text VT's.

Created /var/service/lightdm_tty8 service. For user's convenience,
it's activated by pressing Enter at a chosen tty.
This is the run file:

#!/bin/sh
tty="/dev/${PWD##*/lightdm_}"
need "$tty"
exec <"$tty"
exec >"$tty" 2>&1
# If udevd is not up, X may fail to find any input devices. Wait 
for it.

need /run/udevd_ready
echo "Press Enter to start lightdm"; read junk
echo "* Starting lightdm[$$]"
exec \
env - PATH="$PATH" \
lightdm

Hmm. A tool to wait for a file is needed. So far this should do - 
/bin/need:


#!/bin/sh
i=0
while ! test -e "$1"; do
sleep "0.$i"
test "$i" = 9 || i=$((i+1))
done

Started it. Confirmed that GUI environment starts and seems to work 
just fine.


The big one: make system boot without systemd. Final preparations are:
* Create dbus and udevd services, start them only if systemd is not 
detected.
* Create init scripts. The word "init" here has more than one 
meaning...


Created /var/service/dbus-daemon service. run file:

#!/bin/sh
#exec >/dev/null
exec 2>&1
exec /dev/null
exec 2>&1
exec /run/udevd_ready
echo "Done: trigger+settle"
) &
echo "* Starting systemd-udevd[$$]"
exec \
env - PATH="$PATH" \
/usr/lib/systemd/systemd-udevd

It should auto-shutdown now, since systemd is detected.

Created /init script.

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin

/etc/runit/1

exec 0>&- 1>&- 2>&-
# In this form, shell won't have an open fd to the script file
exec env - sh -c 'while :; do sleep ; done'

Isn't it a cutie.
In the spirit of runit tool, let's run system startup scripts from
/etc/runit/1. Create it:

#!/bin/sh
dir_and_not_mounted() {
test -d "$1" || return 1
! mountpoint -q -- "$1"
}
if fsck -A; then
true
else
echo "fsck exit code: $?. Boot will not continue."
while true; do sleep ; done
fi
mount -o remount,rw /
mount -a
dir_and_not_mounted /proc && mount -t proc proc /proc
dir_and_not_mounted /sys && mount -t sysfs sysfs /sys
# These are mounted by systemd, for some reason not via fstab.
Mimic for now:
dir_and_not_mounted /tmp && mount -t tmpfs tmpfs /tmp

Re: Switching Fedora machine away from systemd

[Denys Vlasenko]

On Thu, Apr 19, 2018 at 5:51 PM, Daniel Glöckner  wrote:
> Am 04/19/18 um 17:18 schrieb Denys Vlasenko:
>> After yet another incident of wandering among endless
>> directories/"targets"/links trying to figure out how to stop
>> the laptop from falling asleep on lid close, I've had enough.
> I also once wasted some time trying to figure that out.
> It's HandleLidSwitch=ignore in logind.conf. Of course it is the
> login manager that controls power management...

Nope, didn't work for me.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Switching Fedora machine away from systemd

[Daniel Glöckner]

Am 04/19/18 um 17:18 schrieb Denys Vlasenko:
> After yet another incident of wandering among endless
> directories/"targets"/links trying to figure out how to stop
> the laptop from falling asleep on lid close, I've had enough.
I also once wasted some time trying to figure that out.
It's HandleLidSwitch=ignore in logind.conf. Of course it is the
login manager that controls power management...

Best regards,

  Daniel

-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke
Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Switching Fedora machine away from systemd

[Denys Vlasenko]

After yet another incident of wandering among endless
directories/"targets"/links trying to figure out how to stop
the laptop from falling asleep on lid close, I've had enough.

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

This also doubles as a test whether busybox's runit tools
are up to the task.

https://busybox.net/ -> [Life without systemd]


Runit tools in busybox - up to the task?

Let's test busybox's runit applets in a hypothetical ;) scenario
when someone needs to stop running, say, systemd on, say, a Fedora machine.

No doubt this will expose various shortcomings.

Started with the machine configured and running under systemd.
Machine has xfce4 desktop environment installed.

Created /var/service and copied busybox/examples/var_service/* there.

Renamed/copied getty_tty1 to getty_tty9/10/11/12 (these consoles are not used
by existing setup).

Deleted dhcpd_if, ftpd, httpd, inetd, nmeter, tftpd (hmm, this needs a way
to store inactive services somewhere in a separate directory).

Adjusted fw/run (need more configurable way to do it; lacks a way to specify
more than one "external" (firewalled) interface).

Renamed/copied dhcp_if, dhcp_if_pinger, ifplugd_if each to a pair
of services for eth0 and wlan0.
Renamed supplicant_if only for wlan0.
Renamed zcip_if only for eth0 (how exactly zeroconf supposed to coexist
on more than one iface? They would all have 169.254/16 subnet - ?!).

Created a user to save all logs under:
groupadd -f --system logger
useradd --system -g logger -d /tmp -s /bin/false logger

Created /var/service/start:

#!/bin/sh
dir=/var/service
export PATH=/sbin:/bin:/usr/sbin:/usr/bin
exec /dev/null 2>&1
umask 022
cd "$dir" || exit $?
exec env - PATH="$PATH" runsvdir -P "$dir"

Created /etc/systemd/system/var.service:

[Unit]
Description=/var/service support
[Service]
ExecStart=/var/service/start

Added symlink: /etc/systemd/system/multi-user.target.wants/var.service ->
-> /etc/systemd/system/var.service

Deinstalled NetworkManager.

Rebooted and tested that services from /var/service do start, and nicely
coexist with the rest of the system.

Tested network (DHCP, zeroconf) and local DNS caching to work.

Now we will pry off X startup from systemd.

Changed /etc/systemd/system/default.target symlink to point to
/lib/systemd/system/multi-user.target instead of a GUI link.
Reboot. Now the system should start with Linux text VT's.

Created /var/service/lightdm_tty8 service. For user's convenience,
it's activated by pressing Enter at a chosen tty.
This is the run file:

#!/bin/sh
tty="/dev/${PWD##*/lightdm_}"
need "$tty"
exec <"$tty"
exec >"$tty" 2>&1
# If udevd is not up, X may fail to find any input devices. Wait for it.
need /run/udevd_ready
echo "Press Enter to start lightdm"; read junk
echo "* Starting lightdm[$$]"
exec \
env - PATH="$PATH" \
lightdm

Hmm. A tool to wait for a file is needed. So far this should do - /bin/need:

#!/bin/sh
i=0
while ! test -e "$1"; do
sleep "0.$i"
test "$i" = 9 || i=$((i+1))
done

Started it. Confirmed that GUI environment starts and seems to work just fine.

The big one: make system boot without systemd. Final preparations are:
* Create dbus and udevd services, start them only if systemd is not detected.
* Create init scripts. The word "init" here has more than one meaning...

Created /var/service/dbus-daemon service. run file:

#!/bin/sh
#exec >/dev/null
exec 2>&1
exec /dev/null
exec 2>&1
exec /run/udevd_ready
echo "Done: trigger+settle"
) &
echo "* Starting systemd-udevd[$$]"
exec \
env - PATH="$PATH" \
/usr/lib/systemd/systemd-udevd

It should auto-shutdown now, since systemd is detected.

Created /init script.

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin

/etc/runit/1

exec 0>&- 1>&- 2>&-
# In this form, shell won't have an open fd to the script file
exec env - sh -c 'while :; do sleep ; done'

Isn't it a cutie.
In the spirit of runit tool, let's run system startup scripts from
/etc/runit/1. Create it:

#!/bin/sh
dir_and_not_mounted() {
test -d "$1" || return 1
! mountpoint -q -- "$1"
}
if fsck -A; then
true
else
echo "fsck exit code: $?. Boot will not continue."
while true; do sleep ; done
fi
mount -o remount,rw /
mount -a
dir_and_not_mounted /proc && mount -t proc proc /proc
dir_and_not_mounted /sys && mount -t sysfs sysfs /sys
# These are mounted by systemd, for some reason not via fstab.
Mimic for now:
dir_and_not_mounted /tmp && mount -t tmpfs tmpfs /tmp
dir_and_not_mounted /run && mount -t tmpfs tmpfs /run
# Remove the mess left by systemd which possibly ran in initramfs:
for d in /sys/fs/cgroup/*