Switching Fedora machine away from systemd
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/* /sys/fs/
Re: Switching Fedora machine away from systemd
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
Re: Switching Fedora machine away from systemd
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
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 dir_
Re: Switching Fedora machine away from systemd
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
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
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, 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
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
>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
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
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 which want to be logged will
Re: Switching Fedora machine away from systemd
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