FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 04-28-2012, 05:58 PM
Kevin Chadwick
 
Default RFC: OpenRC as init system for Arch

On Fri, 27 Apr 2012 19:08:34 +0200
Jan Steffens wrote:

> > We are going to sacrifice, simplicity, amount of code to look for bugs
> > and most importantly, ease of troubleshooting. One of the beauties of
> > Unix is the error information. Aren't they all going to be mixed
> > together on systemd. Imagine if all drivers loaded at once. Ughh Would
> > many resort to Windows style trial and error more often.
>
> One of the features of systemd is the large amount of metadata the
> journal colllects. This allows filtering on the message source, for
> example. Right now that's just the process (and service) that
> generated them, but with the coming udev integration and kernel
> logging improvements, you will also be able to view kernel messages by
> device or module.

Hmmm, interesting, but if it just hangs without a panic then there may
be no kernel message and working out what it was doing by looking at
what it had just done before it hung, would be extremely difficult,
wouldn't it?
 
Old 04-28-2012, 06:12 PM
Kevin Chadwick
 
Default RFC: OpenRC as init system for Arch

On Sat, 28 Apr 2012 18:58:01 +0100
Kevin Chadwick wrote:

> but if it just hangs without a panic

I still like KISS for init but thinking about it, The chances of that
are I'd guess next to none, once the drivers are loaded?

I presume you will be able to get to this journal information even if
you switch off and access the drive in another machine?
 
Old 04-28-2012, 08:27 PM
Tom Gundersen
 
Default RFC: OpenRC as init system for Arch

On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> Imagine if all drivers loaded at once.

Just a piece of information: the way kernel modules are loaded is not
changed, currently they are (for most intents and purposes) loaded at
once.

-t
 
Old 04-28-2012, 08:29 PM
Tom Gundersen
 
Default RFC: OpenRC as init system for Arch

On Sat, Apr 28, 2012 at 8:12 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> I presume you will be able to get to this journal information even if
> you switch off and access the drive in another machine?

You can configure the journal to be saved to disk and process it on a
different machine later on.

-t
 
Old 04-28-2012, 09:05 PM
C Anthony Risinger
 
Default RFC: OpenRC as init system for Arch

On Fri, Apr 27, 2012 at 12:08 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
> On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> We are going to sacrifice, simplicity, amount of code to look for bugs
>> and most importantly, ease of troubleshooting. One of the beauties of
>> Unix is the error information. Aren't they all going to be mixed
>> together on systemd. Imagine if all drivers loaded at once. Ughh Would
>> many resort to Windows style trial and error more often.
>
> One of the features of systemd is the large amount of metadata the
> journal colllects. This allows filtering on the message source, for
> example. Right now that's just the process (and service) that
> generated them, but with the coming udev integration and kernel
> logging improvements, you will also be able to view kernel messages by
> device or module.

yes this is nice :-)

by far and large, systemd is the init system as i imagined it *should*
be, when i first started using linux ... i can't count the number of
times i thought "/sbin/init doesn't do a damn thing, and is utterly
useless"

"bloat" is not measured by LOC, but rather by degrees of uselessness.

i have converted several desktops -- and servers -- to use systemd
*exclusively*. by this i mean i subsequently "pacman -R initscripts
sysvinit". haven't looked back, and not a single issue that wasn't my
own doing.

after a small amount of learning you can bang out unit files with EASE
... just the other day, i wrote a fwknop.service in probably 5 minutes
or less. now i get to do this ...

-----------------------------------
# systemctl status fwknopd.service
fwknopd.service - firewall knock operator daemon
Loaded: loaded (/etc/systemd/system/fwknopd.service; enabled)
Active: active (running) since Sat, 28 Apr 2012 16:06:08
-0400; 37min ago
Main PID: 18452 (fwknopd)
CGroup: name=systemd:/system/fwknopd.service
└ 18452 /usr/sbin/fwknopd --config-file
/etc/fwknop/fwknopd.conf.local --foreground

Apr 28 16:06:08 some-server.xtfx.net fwknopd[18452]: Starting fwknopd
Apr 28 16:06:08 some-server.xtfx.net fwknopd[18452]: Added jump rule
from chain: INPUT to chain: FWKNOP_INPUT
Apr 28 16:06:09 some-server.xtfx.net fwknopd[18452]: PCAP filter is:
udp port 62201
Apr 28 16:06:09 some-server.xtfx.net fwknopd[18452]: Starting fwknopd
main event loop.
Apr 28 16:06:19 some-server.xtfx.net fwknopd[18452]: (stanza #1) SPA
Packet from IP: 1.2.3.4 received with access source match
Apr 28 16:06:19 some-server.xtfx.net fwknopd[18452]: Added Rule to
FWKNOP_INPUT for 1.2.3.4, tcp/22 expires at 1335643609
Apr 28 16:06:49 some-server.xtfx.net fwknopd[18452]: Removed rule 1
from FWKNOP_INPUT with expire time of 1335643609.
-----------------------------------

... (root needed to see journal) see all that extra info after the
status? that's the systemd journal capturing the stdout of the
foreground process it monitors. the syslog-like timestamps are added
by systemd.

i have custom units managing daemons like this, timers syncing
archlinux mirrors, units modifying /sys/ tunables (there is no
`sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...

... and on servers especially, i even have units bound to ethernet
devices, automatically managing the interface, and/or starting dhcp!

-----------------------------------
# systemctl status net-dyn-phys@eth0.service
Password:
net-dyn-phys@eth0.service - dynamic inet interface [phys:eth0]
Loaded: loaded
(/etc/systemd/system/sys-subsystem-net-devices-eth0.device.wants/../net-dyn-phys@.service;
enabled)
Active: active (running) since Thu, 26 Apr 2012 23:38:40
-0400; 1 day and 17h ago
Main PID: 175 (dhcpcd)
CGroup: name=systemd:/system/net-dyn-phys@.service/eth0
└ 175 /usr/sbin/dhcpcd --config /etc/dhcpcd.conf.local eth0

Apr 26 23:38:45 some-server.xtfx.net dhcpcd[175]: eth0: leased 5.6.7.8
for 86400 seconds
Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: renewing lease
of 5.6.7.8
Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: acknowledged
5.6.7.8 from 74.207.239.122
Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: leased 5.6.7.8
for 86400 seconds
-----------------------------------

... and i plan to make this even more automatic/intelligent in the
future. i also use a handful of other units developed by Exherbo
(git-daemon) that required no changes whatsoever to work for
Archlinux. how's that for cross-platform?

in summary: systemd is fanta-bulous ... and IMO, anything less is just
as useless as that which preceded it. i have no reservations
for-or-against OpenRC, but systemd is the new precedent for
how-to-build-an-init-system-for-modern-systems.

--

C Anthony
 
Old 04-28-2012, 11:43 PM
Kevin Chadwick
 
Default RFC: OpenRC as init system for Arch

On Sat, 28 Apr 2012 22:27:49 +0200
Tom Gundersen wrote:

> Just a piece of information: the way kernel modules are loaded is not
> changed, currently they are (for most intents and purposes) loaded at
> once.

I didn't know that, annoying. There aren't that many though as I
manually enable them before disabling module loading. I believe core
kernel drivers are loaded nice and sequentially? There's still some
searching in the dark just less dark to search in, without enabling
debugging features.
 
Old 04-29-2012, 12:16 AM
Kevin Chadwick
 
Default RFC: OpenRC as init system for Arch

On Sat, 28 Apr 2012 16:05:54 -0500
C Anthony Risinger wrote:

> "bloat" is not measured by LOC, but rather by degrees of uselessness.
>

I disagree here. If many don't use/need those features aside from an
init system initialising things then it is bloat and will have bugs
that will even affect simple firewall systems. Of course I'd use
OpenBSD for a firewall but I know some build a highly stripped down
Linux (kernel).


I hope there's no, well this is cool, and this bits wrong fundamentally
but we and others have done so much work, lets just carry on. Windows
registry springs to mind. Recent events like binary and random config
file locations keep me wondering if the support companies so heavily
involved in Linux have motives to make Linux harder to fix and
customise. I like sed and diff, thankyou very much, I don't want to
learn a thousand different config tools and formats ironically in the
name of 'ease' or 'speed/compatibility' to shut many complainers up.

OpenBSD - hotplugd, sudo - nice and simple.

Linux - udev, polkit and friends - what a mess, where shall I start. Oh
the beginning, right I'll read this book and then I'll know where the
beginning is, of course if somethings configured this then actually
there's a new beginning.

Sorry didn't mean to rant just saying what I see from over complex
newness disregarding strong unix heritage like cross-distro things
such as dconf and gconf bring.

Rather than some conspiracy I'd hope/expect it's simply that having
many many coders bring wanted features but also unstoppable misdirected
trains as there aren't enough top notch respected eyes to notice before
it's too late. Elephantitis.


> i have custom units managing daemons like this, timers syncing
> archlinux mirrors, units modifying /sys/ tunables (there is no
> `sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
>
> ... and on servers especially, i even have units bound to ethernet
> devices, automatically managing the interface, and/or starting dhcp!

Could you be explicit in what you've gained. Maybe I'm ignorrant of the
details but I see perhaps this functionality being more universal and
that's it?
 
Old 04-29-2012, 03:10 AM
C Anthony Risinger
 
Default RFC: OpenRC as init system for Arch

On Sat, Apr 28, 2012 at 7:16 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Sat, 28 Apr 2012 16:05:54 -0500
> C Anthony Risinger wrote:
>
>> "bloat" is not measured by LOC, but rather by degrees of uselessness.
>
> I disagree here. If many don't use/need those features aside from an
> init system initialising things then it is bloat and will have bugs
> that will even affect simple firewall systems. Of course I'd use
> OpenBSD for a firewall but I know some build a highly stripped down
> Linux (kernel).

perhaps it is a matter of taste, but i don't think the init system's
purpose is to simply "initialize" things. it is a state manager, esp.
considering it has abilities no other process has. i wish i could
find the link now, but i read an excerpt regarding the original design
philosophy of the init program ... and while it wasn't 100% straight
forward, the original goals heavily alluded that init was a
intelligent supervisor, and not nearly as dumb as we now know it.

for LXC systems, i previously wrote an "init" in bash, that could
parse inittab, and respond to SIGPWR and SIGINT (powerfail and
crtlaltdelete in inittab), i probably 100 LOC of bash. basic
functionality was implemented in far less ... what's the point? now i
have to write everything in shell scripts for stuff that could
perfectly well be handled by the supervisor.

i write a lot of shell code, and have literally read the bash man page
enough times to be able to jump to any point for reference ... shell
code is anything but secure and rather fragile. it's just not meant
to do as much as we make it. you are probably right about the
firewall case, maybe it wouldn't be needed. but my guess is that you
could actually make the firewall much more fault tolerant and
intelligent by using such a powerful supervisor as systemd. for the
most part though, most systems *do* require intricate and complex
relationships between services, and systemd fills that need
splendidly, *because* it does more that "fire and forget" [initialize]
processes.

> I hope there's no, well this is cool, and this bits wrong fundamentally
> but we and others have done so much work, lets just carry on. Windows
> registry springs to mind. Recent events like binary and random config
> file locations keep me wondering if the support companies so heavily
> involved in Linux have motives to make Linux harder to fix and
> customise. I like sed and diff, thankyou very much, I don't want to
> learn a thousand different config tools and formats ironically in the
> name of 'ease' or 'speed/compatibility' to shut many complainers up.

what binary configs? are you referencing? in systemd's case anyway,
the unit files all look like simple key/value environment files, and
are easily parseable by anything. my favorite in this arena is
augeas, because it takes any config file and makes it reliably
editable ... sed is nice and all, and i use it rather heavily for
daily tasks, but it's not suitable for editing other peoples stuff in
an automatic and predictable way.

personally, i'd like to see a configfs of sorts so i could edit all
configs from a single hierarchy (python + augeas + FUSE ... *hint
hint* ... someday :-)

> OpenBSD - hotplugd, sudo - nice and simple.
>
> Linux - udev, polkit and friends - what a mess, where shall I start. Oh
> the beginning, right I'll read this book and then I'll know where the
> beginning is, of course if somethings configured this then actually
> there's a new beginning.
>
> Sorry didn't mean to rant just saying what I see from over complex
> newness disregarding strong unix heritage like cross-distro things
> such as dconf and gconf bring.
>
> Rather than some conspiracy I'd hope/expect it's simply that having
> many many coders bring wanted features but also unstoppable misdirected
> trains as there aren't enough top notch respected eyes to notice before
> it's too late. Elephantitis.

i think systemd offers a nice way to not only start your processes,
but also maintian their relationship to the rest of the system.
traditional init systems work fine ... so long as everything works
correctly on first try. if you want to have any kind of faul
tolerance, or even recovering from minor outages/hiccups, you suddenly
need all this extra infrastructure to watch pid files, watch
directories, watch watch watch ... while meanwhile, your init system
is standing in the corner picking it's nose, because it "did it's job
already" and all it needed to do was "start some stuff in the first 5
seconds".

>> i have custom units managing daemons like this, timers syncing
>> archlinux mirrors, units modifying /sys/ tunables (there is no
>> `sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
>>
>> ... and on servers especially, i even have units bound to ethernet
>> devices, automatically managing the interface, and/or starting dhcp!
>
> Could you be explicit in what you've gained. Maybe I'm ignorrant of the
> details but I see perhaps this functionality being more universal and
> that's it?

i just want things to happen at the right moments without worry, reuse
as much as possible, and not need to introduce additional requirements
... in the end i'm quite sure we have the same goals :-)

i know this isn't the final way i'll do it, but i currently use this
unit file on ~3 servers:

-----------------------------------
# Bindings to physical interfaces

[Unit]
Description=dynamic inet interface [phys:%I]
Wants=network.target
Before=network.target
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
After=systemd-user-sessions.service rc-local.service

[Service]
Type=simple
TimeoutSec=0
Restart=always
RestartSec=10
EnvironmentFile=/etc/conf.d/dhcpcd
PIDFile=/run/dhcpcd-%I.pid
ExecStart=-/usr/sbin/dhcpcd $DHCPCD_ARGS %I
ExecStop=-/usr/sbin/dhcpcd --exit %I

[Install]
Alias=sys-subsystem-net-devices-eth0.device.wants/net-dyn-phys@eth0.service
-----------------------------------

... with just what you see above, and no modifications between
systems, i can run a dhcp service on any interface, whether it exists
or not, by only making a single symlink for each interface needed.
when a particular interface comes into being, dhcp will be started.
when the interface disappears, dhcp will be killed and the unit
"shutdown". if dhcp dies but the interface still exists, it will be
restarted. this unit activates the network.target, but guarantees
that all units depending on the network will wait until it's finished
before being started themselves.

... doing to same with an init script requires a much more work, a lot
more boilerplate code, and probably another process or two+.

--

C Anthony
 
Old 04-29-2012, 04:51 AM
Patrick Lauer
 
Default RFC: OpenRC as init system for Arch

On 04/29/12 11:10, C Anthony Risinger wrote:
> On Sat, Apr 28, 2012 at 7:16 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> On Sat, 28 Apr 2012 16:05:54 -0500
>> C Anthony Risinger wrote:
>>
>>> "bloat" is not measured by LOC, but rather by degrees of uselessness.
>> I disagree here. If many don't use/need those features aside from an
>> init system initialising things then it is bloat and will have bugs
>> that will even affect simple firewall systems. Of course I'd use
>> OpenBSD for a firewall but I know some build a highly stripped down
>> Linux (kernel).
> perhaps it is a matter of taste, but i don't think the init system's
> purpose is to simply "initialize" things. it is a state manager, esp.
> considering it has abilities no other process has. i wish i could
> find the link now, but i read an excerpt regarding the original design
> philosophy of the init program ... and while it wasn't 100% straight
> forward, the original goals heavily alluded that init was a
> intelligent supervisor, and not nearly as dumb as we now know it.
well, the sysvinit /sbin/init is very good at being PID 1 ... the state
manager gets started and/or kept alive by it - and there's so little
code involved that there are no surprises.
The sysvinit code is so "boring" that there are still typos in the
comments because not enough people even look at it to notice ...

>
> for LXC systems, i previously wrote an "init" in bash, that could
> parse inittab, and respond to SIGPWR and SIGINT (powerfail and
> crtlaltdelete in inittab), i probably 100 LOC of bash. basic
> functionality was implemented in far less ... what's the point? now i
> have to write everything in shell scripts for stuff that could
> perfectly well be handled by the supervisor.
acpid for SIGPWR, ca:12345:ctrlaltdel:/sbin/shutdown -r now for SIGINT,
oh wait, my defaults already do that

And I didn't have to write any code for that ...
>
> i write a lot of shell code, and have literally read the bash man page
> enough times to be able to jump to any point for reference ... shell
> code is anything but secure and rather fragile. it's just not meant
> to do as much as we make it. you are probably right about the
> firewall case, maybe it wouldn't be needed. but my guess is that you
> could actually make the firewall much more fault tolerant and
> intelligent by using such a powerful supervisor as systemd. for the
> most part though, most systems *do* require intricate and complex
> relationships between services, and systemd fills that need
> splendidly, *because* it does more that "fire and forget" [initialize]
> processes.
Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
(hello threaded Intercal!)

In my opinion, if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.


[snip]
> Rather than some conspiracy I'd hope/expect it's simply that having
> many many coders bring wanted features but also unstoppable misdirected
> trains as there aren't enough top notch respected eyes to notice before
> it's too late. Elephantitis.
> i think systemd offers a nice way to not only start your processes,
> but also maintian their relationship to the rest of the system.
So the only weak argument in favour of systemd is dependency handling,
which has been around for a decade. Oh, and if you have stateful init
scripts (yeah, radical, I know) you can just check if all services you
wanted to start are started and still alive. (running "rc-status" and
"rc" with openrc does exactly that)

No need for systemd at all

> traditional init systems work fine ... so long as everything works
> correctly on first try. if you want to have any kind of faul
> tolerance, or even recovering from minor outages/hiccups, you suddenly
> need all this extra infrastructure to watch pid files, watch
> directories, watch watch watch ...
that's why I offered OpenRC as an alternative - it does all those things
while still being boring and manageable.

> while meanwhile, your init system
> is standing in the corner picking it's nose, because it "did it's job
> already" and all it needed to do was "start some stuff in the first 5
> seconds".
So fix your init system
>
>>> i have custom units managing daemons like this, timers syncing
>>> archlinux mirrors, units modifying /sys/ tunables (there is no
>>> `sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
>>>
>>> ... and on servers especially, i even have units bound to ethernet
>>> devices, automatically managing the interface, and/or starting dhcp!
>> Could you be explicit in what you've gained. Maybe I'm ignorrant of the
>> details but I see perhaps this functionality being more universal and
>> that's it?
> i just want things to happen at the right moments without worry, reuse
> as much as possible, and not need to introduce additional requirements
> ... in the end i'm quite sure we have the same goals :-)
>
> i know this isn't the final way i'll do it, but i currently use this
> unit file on ~3 servers:
[snip]
> ... with just what you see above, and no modifications between
> systems, i can run a dhcp service on any interface, whether it exists
> or not, by only making a single symlink for each interface needed.
> when a particular interface comes into being, dhcp will be started.
> when the interface disappears, dhcp will be killed and the unit
> "shutdown". if dhcp dies but the interface still exists, it will be
> restarted. this unit activates the network.target, but guarantees
> that all units depending on the network will wait until it's finished
> before being started themselves.
ln -s /etc/init.d/net.lo /etc/init.d/net.eth3; /etc/init.d/net.eth3
start <-- there's eth3 running with dhcp

And for the dynamic case where you don't know the device name ahead of
time I'd suggest using NetworkManager - it's built to handle all that
jazz. Oh, and if you have a sane init system it'll know in what state NM
is and thus be able to delay starting services that rely on a network
connection.

Or, if you are really kinky, write udev rules to do such things. It's
less code than the unit file ... and udev *is* the event handler for
such things.
>
> ... doing to same with an init script requires a much more work, a lot
> more boilerplate code, and probably another process or two+.
>
You could do it like that, yes ... but isn't that a bit overengineered?

Oh well. It's great that you're discovering features, but systemd isn't
without alternative. Most of the features you mention have been in
OpenRC since the beginning (and that's just a rewrite of the old
baselayout scripts that are about a decade old).

Take care,

Patrick
 
Old 04-29-2012, 06:12 AM
C Anthony Risinger
 
Default RFC: OpenRC as init system for Arch

On Sat, Apr 28, 2012 at 11:51 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 04/29/12 11:10, C Anthony Risinger wrote:
>>
>> perhaps it is a matter of taste, but i don't think the init system's
>> purpose is to simply "initialize" things. *it is a state manager, esp.
>> considering it has abilities no other process has. *i wish i could
>> find the link now, but i read an excerpt regarding the original design
>> philosophy of the init program ... and while it wasn't 100% straight
>> forward, the original goals heavily alluded that init was a
>> intelligent supervisor, and not nearly as dumb as we now know it.
>
> well, the sysvinit /sbin/init is very good at being PID 1 ... the state
> manager gets started and/or kept alive by it - and there's so little
> code involved that there are no surprises.
> The sysvinit code is so "boring" that there are still typos in the
> comments because not enough people even look at it to notice ...

yeah ... i'm a C novice, and i'm pretty sure i can write a stable init
... that's kinda the point. init is so incredibly dumb that it
requires no code. is that really what "unix philosophy" is meant to
convey? so little code and functionality?

#include <stdio.h>
int main() {
printf( "Hello Unix!
" );
return 0;
}

... done! and rock-solid stable! :-)

>> for LXC systems, i previously wrote an "init" in bash, that could
>> parse inittab, and respond to SIGPWR and SIGINT (powerfail and
>> crtlaltdelete in inittab), i probably 100 LOC of bash. *basic
>> functionality was implemented in far less ... what's the point? *now i
>> have to write everything in shell scripts for stuff that could
>> perfectly well be handled by the supervisor.
>
> acpid for SIGPWR, ca:12345:ctrlaltdel:/sbin/shutdown -r now for SIGINT,
> oh wait, my defaults already do that
>
> And I didn't have to write any code for that ...

traditional init will lock up the container because it thinks it must
reboot/shutdown the system. there is absolutely no way to make it
kill itself, and end the container "normally". it has to be kill
-9'ed from the outside.

... systemd on the other had, realizes it's running in a container,
and simply exit()'s.

>> i write a lot of shell code, and have literally read the bash man page
>> enough times to be able to jump to any point for reference ... shell
>> code is anything but secure and rather fragile. *it's just not meant
>> to do as much as we make it. *you are probably right about the
>> firewall case, maybe it wouldn't be needed. *but my guess is that you
>> could actually make the firewall much more fault tolerant and
>> intelligent by using such a powerful supervisor as systemd. *for the
>> most part though, most systems *do* require intricate and complex
>> relationships between services, and systemd fills that need
>> splendidly, *because* it does more that "fire and forget" [initialize]
>> processes.
>
> Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
> (hello threaded Intercal!)
>
> In my opinion, *if I have to start hacking random C to add or adapt
> features (which happens as soon as the builtins do the wrong things -
> that's about twice a year for me) it'll be a lot more crashy than a
> simple shell script where I add one line of code.

well, i've used systemd for quite some time, and have never needed to
hack any C. you can always ruin shellscripts from unit files if you
like, no one is preventing that.

the introspective and investigation tools in systemd are excellent and
unmatched by any other "alternative" i've encountered ... have you
actually tried it yet? if i want to know what my systems is doing as
a whole, who better to ask that the ONE process capable of telling me?
pid 1 can do stuff no other can ... why squander such powers?

> [snip]
>> Rather than some conspiracy I'd hope/expect it's simply that having
>> many many coders bring wanted features but also unstoppable misdirected
>> trains as there aren't enough top notch respected eyes to notice before
>> it's too late. Elephantitis.
>> i think systemd offers a nice way to not only start your processes,
>> but also maintian their relationship to the rest of the system.
>
> So the only weak argument in favour of systemd is dependency handling,
> which has been around for a decade. Oh, and if you have stateful init
> scripts (yeah, radical, I know) you can just check if all services you
> wanted to start are started and still alive. (running "rc-status" and
> "rc" with openrc does exactly that)
>
> No need for systemd at all

and doing that from a remote tool? right ... run command XYZ over
ssh, parse for ABC, etc etc. what about timed stuff? what about
events/services that are not daemons? i'm a developer; i want real
interfaces to use, with precise endpoints and clear methods. dbus
does this nicely. in time, i can query more and more over dbus.

when i have a hundred systems, i very much do not want to babysit
them. systemd and the associated thought path really is a great step
forward. yes shell is nice. i write uber-tons of shell. but the
unit files are clean, simple, consistent, and powerful. read some of
the man pages ... tell me how to do all that with shell and/or OpenRC
alone, because people *want* this! else systemd would not exist, nor
have so much impetus.

>> traditional init systems work fine ... so long as everything works
>> correctly on first try. *if you want to have any kind of faul
>> tolerance, or even recovering from minor outages/hiccups, you suddenly
>> need all this extra infrastructure to watch pid files, watch
>> directories, watch watch watch ...
>
> that's why I offered OpenRC as an alternative - it does all those things
> while still being boring and manageable.

manageable? any init system that claims to only be /sbin/init is
deluding itself. "init" is all the rc scripts, the init app itself,
all the daemon rc scripts ... *everything*. systemd will spew out a
graphviz chart if i want. or let me start units one by one during
boot in an interactive way ... what can OpenRC do above-and-beyond,
for ME, the interrogator?

>> *while meanwhile, your init system
>> is standing in the corner picking it's nose, because it "did it's job
>> already" and all it needed to do was "start some stuff in the first 5
>> seconds".
>
> So fix your init system

luckily someone did it for me!

>> ... with just what you see above, and no modifications between
>> systems, i can run a dhcp service on any interface, whether it exists
>> or not, by only making a single symlink for each interface needed.
>> when a particular interface comes into being, dhcp will be started.
>> when the interface disappears, dhcp will be killed and the unit
>> "shutdown". *if dhcp dies but the interface still exists, it will be
>> restarted. *this unit activates the network.target, but guarantees
>> that all units depending on the network will wait until it's finished
>> before being started themselves.
>
> ln -s /etc/init.d/net.lo /etc/init.d/net.eth3; /etc/init.d/net.eth3
> start <-- there's eth3 running with dhcp
>
> And for the dynamic case where you don't know the device name ahead of
> time I'd suggest using NetworkManager - it's built to handle all that
> jazz. Oh, and if you have a sane init system it'll know in what state NM
> is and thus be able to delay starting services that rely on a network
> connection.

heyo! networkmanager on a server is going to be an even tougher sell
than systemd. in virtualized environments, hardware can be much more
dynamic than physical servers would experience ... but this was only
an example, and far more interesting examples exist on the
inter-tubes.

> Or, if you are really kinky, write udev rules to do such things. It's
> less code than the unit file ... and udev *is* the event handler for
> such things.

udev is meant to manage symlinks to stuff in dev, and trigger
short-lived apps to do similar book-keeping, not manage or kickoff
services. in systemd's case, a single udev rule is used to tag
devices which are then exported and usable by unit files.

>> ... doing to same with an init script requires a much more work, a lot
>> more boilerplate code, and probably another process or two+.
>
> You could do it like that, yes ... but isn't that a bit overengineered?

how so? what if dhcpcd has a bug, and spontaneously blows up?
systemd will catch the output, the exit code, and other infos, then
restart it for me. when something does exactly what i need, in 10
lines of key/val declarations, that's more like precise engineering in
my book.

--

C Anthony
 

Thread Tools




All times are GMT. The time now is 02:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org