On 20/04/2018 10:45, Denys Vlasenko wrote:
> On Fri, Apr 20, 2018 at 1:08 AM, Laurent Bercot <ska-skaw...@skarnet.org>
> 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 ? Ssl 0: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<s 0:00 /usr/sbin/ntpd -f /etc/openntpd/ntpd.conf -p
/var/run/openntpd.pid
9649 ? Ss 0:00 /usr/sbin/sshd
14269 ? Ss 0:00 /usr/lib/postfix/sbin/master -w
17707 ? Ss 0:00 /usr/bin/dbus-daemon --system
18226 ? Ss 0:00 /usr/sbin/openvpn --writepid
/run/openvpn/server_udp.pid --daemon ovpn-server_udp --cd /etc/o
18929 ? Sl 4:44 /usr/bin/python3 /usr/bin/fail2ban-server -s
/var/run/fail2ban/fail2ban.sock -p /var/run/fail
18959 ? Ss 2:47 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
18997 ? Ss 0:00 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf br0
19026 tty1 Sl 0:00 /usr/sbin/pcscd
21465 ? Ss 0:00 /usr/sbin/squid -YC -f /etc/squid/squid.conf
21467 ? Sl 4:56 (squid-1) -YC -f /etc/squid/squid.conf
22489 ? S 0:23 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
22717 ? Ss 0:49 /usr/sbin/unbound
24582 ? Ss 0:09 /usr/bin/perl /usr/share/webmin/miniserv.pl
/etc/webmin/miniserv.conf
30065 ? Ss 0:00 /lib/systemd/systemd-udevd --daemon
> 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
