On Sun, 18 Feb 2018 21:57:30 -0500
Post by Solomon Peachy via AlePost by Steve Litt via AleIt also isn't all that necessary. Most run scripts, as they come
from the factory (at least with Void Linux) have no process
dependency checking, and in practice things seem to work just fine.
But if one wants process dependency checking, it simply requires a
simple "if" statement within the dependent process' run script.
So... if the parent restarts, who is going to restart the dependents?
I was discussing dependent daemons that depend on a dependency daemon.
When one or both crash, Runit restarts it/them within 5 seconds.
Now you're talking about parents and what, dependents, children? You
mean like Apache, which forks a process for each connection? With
software I've seen, the parent cleans up the children. If the parent
crashes, it sends a hup or something to the children, which should
cause them to shut down. With the software I've seen, if a daemon forks
processes, it's not the init system's business to track them, kill or
restart any "children."
Anyway, a runit run script can run a background process and then exec to
the daemon to be run, or it can send itself a message to start a
different daemon before starting the one it's supposed to start. It's a
shellscript: The possibilities are infinite.
And before someone else brings it up, it's a very different kind of
shellscript than the 300 line S12_my_daemon_five_event_script thingys.
I don't think I ever saw a run script more than 15 lines long, and most
are under 7.
Post by Solomon Peachy via AlePost by Steve Litt via AleRunit can do that. I'm not sure it's a good idea: I'd rather ip link
set dev eth0 down;ip link set dev eth0 up, and same with wlo1. With
such a change, I'd rather fix it up manually. For situations where
the network goes down and back up again, all I can say is my
computer brings back its network connection without the need of
having the network be a service.
I'd rather _not_ fix things up manually, by the time I've finished
everyhing it would have been faster (and less disruptive) to just
reboot the system.
Oh come mon man:
ip link set dev eth0 down
ip link set dev eth0 up
ip link set dev wl01 down
ip link set dev wl01 up
Put em in a shellscript. While you're at it, end the shellscript with a
test for upness:
ip addr list
[snip]
Post by Solomon Peachy via AlePost by Steve Litt via AleProblem is, with systemd's welded together entanglement of large
sections of software with applications and the underlying OS,
systemd completely changes the way you adjust your software, and
IMHO not for the better if you're at all DIY.
You and I draw the "DIY" line at different places.
Geez, I never noticed that. I bet nobody else did either :-)
You and I obviously draw *a lot* of lines in different places.
Post by Solomon Peachy via Ale(I don't administer my own systems for the joy of it; they have
specific jobs to fulfil and I'm too much of a paranoid git to trust
my data on anyone else's systems..)
Who in the world administers their systems for the joy of it? Nobody I
know. DIY people administer their systems to make their systems do
things how *they* want them done. To mold their computer to their use
case, whether they type 120 WPM or 5 WPM. Is their vision 20/10, or
20/60 corrected? Do they think logically like a computer, or flightily
like a human? Do you have breaks in your workday that neatly
accommodate that 5 minute process, or do you have to go full out every
minute of the day? Each one of these things influences your optimal
user interface, so you change your interface via DIY.
Some people choose a distro to accommodate their workflow. This becomes
problematic when different distros have various of your optimal user
interface elements. Who can forget the blind exodus from Ubuntu when
Ubuntu replaced Gnome with (urk) Unity? DIY people just changed the
WM/DE (Window manager/Desktop environment) and moved on.
I spent 2 days making a home-grown hierarchical menu program in
1999, and have used it as part of my workflow ever since, including
quickly bolting on a menu interface to an executable program with very
complex command line args. DIY people do this: They replace repetitive
riffs with menus, shellscripts, whatever. A little more work up front,
a lot more relaxation going forward.
And in their travels, DIY people learn the value of simple modules
connected only on a need to know basis via simple, small and well
documented interfaces. I'm not going to explain it to you: I learned it
when I used to fix electronics for a living: Systems that are easily
separated are easily troubleshot, easily repaired, and easily modified.
DIY people don't put up with units interconnected every which way by
thick, complex tentacles or even thick, go everywhere busses.
DIY isn't for everyone. It takes a little extra work up front. It takes
certain skills not everyone has. It invariably runs afoul of what's
popular, because features and brokenness drive new purchases: DIY cuts
into profits.
SteveT
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo