Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On 10/25/2014 04:55 PM, Matthew Petach wrote: Completely agree on this point--but I fail to see why it has to be one or the other? Why can't systemd have a --text flag to tell it to output in ascii text mode for those of us who prefer it that way? It still logs to syslog, and syslog can still log to text. Systemd certainly writes a nice text /var/log/messages on my CentOS 7 system. There is also a --log-target command line option, where there are several possible targets. Further, the binary log is generated by journald, not by systemd itself, which can log directly to syslog without using the binary journal (see: http://fitzcarraldoblog.wordpress.com/2014/09/20/change-systemds-binary-logging-to-text-logging-in-sabayon-linux/ for how to do this in one particular Linux distribution, Sabayon). The more I dig into systemd, the less I dislike it. I'm still not thrilled, but it's not as bad as I first heard it was going to be.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, 25 Oct 2014 17:56:52 -0500, Jimmy Hess said: The next thing you know, SystemD will add package management, ISO building, and eliminate the need for Debian, Ubuntu, SuSE, Redhat, Etc to even exist. That's already on Lennart's to-do list, you know. pgpsrz4mwPqsz.pgp Description: PGP signature
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Fri, Oct 24, 2014 at 10:10 AM, Jim Mercer j...@reptiles.org wrote: On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote: All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts. in FreeBSD, the bulk of the rc.d scripts are basically the same format, inhaling a standardized library of functions, populating some variables, maybe adding a few custom functions, then jumping to main. If all of the scripts are cut'n'paste copes of each other, wouldn't it be better to figure out a way to stop cutting and pasting? I can't count the number of times I've run into problems with my code because of that, never mind how many times it's happened in other people's code. -- Jeff Ollie
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On 10/25/2014 08:12 AM, Jeffrey Ollie wrote: If all of the scripts are cut'n'paste copes of each other, wouldn't it be better to figure out a way to stop cutting and pasting? I can't count the number of times I've run into problems with my code because of that, never mind how many times it's happened in other people's code. I suggest that the corruption and rot was introduced when we left /etc/inittab as the sole way to run permanent daemons. We had telinit(8) already to change run levels, so expanding on telinit would have been more sensible -- telinit itself to change temporarily things temporarily (start, stop, restart), and something that modified the inittab (editor? script? GUI?) to make changes that last across boots. The first change would be to expand the daemon identifier from two characters to proper labels...but I digress. The whole rc script thing strikes me as an interim solution that required a minimum of code changes (graduate student project?) that went viral. Bad as it was, it worked. Duct tape and bailing wire Why did we have copy-and-paste for so long? The answer is in the form of another question: who was willing to take the time to re-factor the Sys-V way of doing things? Was re-factor even in the vocabulary in those days? Systemd is not a re-factoring. It's a from-scratch do-over. What it does that is good is that it provides dependency capability not available in the original inittab. It makes dependency resolution named-based (named semaphores) instead of number-based, which is what the Sys-V method used. The result is far more parallelism in system start-up than afforded by ethier of the previous methods. (I can't speak to Upstart -- I've never really understood it, or how to go from SysV to Upstart. I even filed a bug on this last point against Upstart, and saw not even you stupid . Will it die?) Much of the heartburn I've been observing isn't about core systemd itself, or the goals of systemd itself, but about the culture that had grown around this replacement for the gaggle of shell scripts and the one-line-per-daemon table. Like a gun, the weapon doesn't kill people; it's the operator behind the trigger who is aiming the business end in bad directions. Much of the belly-aching has been about ripple effects that are tangential to systemd itself -- it's unfortunate that these tangents are tied to systemd, it's been said time and time again you don't like it, you can do something about it. It means you can't use the entire package out of the box without changing more than a set of configuration files. My particular bone is NTP substitution -- I'd like to use my cesium clock on my Stratum 1 time server without having to spend an afternoon trying to hork everything together. I'd like for my Stratum II time server to work out of the box with the time servers *I* select, using the University of Delaware software. Oh, and I hate binary logs. Period. If you can't stand plain text, then try XML. At least humans have a *chance* to read it without having to make fancy reader tools.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, Oct 25, 2014 at 10:22 AM, Stephen Satchell l...@satchell.net wrote: ... Oh, and I hate binary logs. Period. If you can't stand plain text, then try XML. At least humans have a *chance* to read it without having to make fancy reader tools. Completely agree on this point--but I fail to see why it has to be one or the other? Why can't systemd have a --text flag to tell it to output in ascii text mode for those of us who prefer it that way? The appeal to Unix versus Windows/MacOS for me was that Unix variants believed in choice and flexibility; I find it odd to see that idea falling out of fashion now. It would seem like the systemd developers could reduce a lot of resistance simply by adding the option to emit output as text logs instead of binary logs for us Crusty Old Farts(tm). Matt
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, Oct 25, 2014 at 1:55 PM, Matthew Petach mpet...@netflight.com wrote: Why can't systemd have a --text flag to tell it to output in ascii text mode for those of us who prefer it that way? It does. --no-pager -- Pete
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, Oct 25, 2014 at 01:55:43PM -0700, Matthew Petach wrote: On Sat, Oct 25, 2014 at 10:22 AM, Stephen Satchell l...@satchell.net wrote: Oh, and I hate binary logs. Period. If you can't stand plain text, then try XML. At least humans have a *chance* to read it without having to make fancy reader tools. Completely agree on this point--but I fail to see why it has to be one or the other? Why can't systemd have a --text flag to tell it to output in ascii text mode for those of us who prefer it that way? Because Lennart knows better than you. - Matt -- Igloo I remember going to my first tutorial in room 404. I was most upset when I found it.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, Oct 25, 2014 at 02:41:55PM -0700, Peter Baldridge wrote: On Sat, Oct 25, 2014 at 1:55 PM, Matthew Petach mpet...@netflight.com wrote: Why can't systemd have a --text flag to tell it to output in ascii text mode for those of us who prefer it that way? ^ This | is not what that | does v It does. --no-pager Unless I'm grossly misreading the manpages that Google things are relevant. - Matt -- Just because we work at a University doesn't mean we're surrounded by smart people. -- Brian Kantor, in the monastery
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, Oct 25, 2014 at 12:22 PM, Stephen Satchell l...@satchell.net wrote: The whole rc script thing strikes me as an interim solution that required a minimum of code changes (graduate student project?) that went viral. Bad as it was, it worked. Duct tape and bailing wire [snip] Systemd is not a re-factoring. It's a from-scratch do-over. What it does that is good is that it provides dependency capability not available in the original inittab. It makes dependency resolution [snip] The trouble is not that systemd is a re-factoring or that it is a do-over. The problem is that the scope of the systemd project is way too large and is ever-expanding! The next thing you know, SystemD will add package management, ISO building, and eliminate the need for Debian, Ubuntu, SuSE, Redhat, Etc to even exist. In the extreme case, at that point, we can rename GNU/Linux to GNU/SystemD,because hey, the Linux kernel is really just a little wrapper around the hardware to support the SystemD userland. The introduction of dependency support is solving issues with SysV init that are problems; I will give you that, but copy and paste init scripts and sequence-based dependencies are largely an aesthetic issue. SysV Init also has the advantage of more deterministic system startup behavior. What do you think happens when you have SystemD, but one of the critical packages has a service dependency incorrectly defined? If the scope of SystemD were appropriately constrained, it would not be also trying to replace the standard SYSLOG facilities with a program-specific logging format for everything. I'm not saying that Syslog is great; perhaps there should be new binary logging formats, orLibc built-in logging to a RDBMs, Redis database, or ElasticSearch cluster,but a distribution's choice of INIT program should not be forcing a choice on you in itself. Also since there are NTP daemons, DHCP, etc, all shipping with SystemD, chances are using something different will be along the path of greatest resistance. If history will be any guide;having all these extra services under the same package init, will likely mean that the maintenance will leave much to be desired and you will be forced to upgrade other things and probably a reboot just to get a bug fix or security patch for your NTP client daemon. It doesn't really matter if they are not all running as PID #1.The problem is really that these services have been lumped into the scope of the same project. Proper integration into a software system does not mean expanding your scope duplicating other programs' functionality into your program, while introducing your own quirks. -- -JH
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
I pled the Linux people to stay inside the unix philosophy to use text files. Low newbies like me learn from reading config files, and fix thing by reading log files, tryiing to make some sense of the error messages there, and using the most suspicious line as the handle to google for a solution (that is often some stackoverflow article, or some forum posts). I dismay after the idea of somebody replacing all that text by a binary that spouts the service stoped running or that corrupt, because some buffer was not flush when the kerfukle happened. Even if going to binary gives a extra 20% speed, I think speed is important but not that important. I plead save the discoverability, learn-bility, debug-ness of text (even text scripts) over mysterious binary blobs elfs generating mysterious binary blobs journals. If they nerf text files, is like they nerf Google for me, and my ability to maintain and configure systems. -- -- ℱin del ℳensaje.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On 10/24/2014 03:35 AM, Tei wrote: I pled the Linux people to stay inside the unix philosophy to use text files. You do realize that the systemd config files are still text, right? As to the binary journal, well, by default RHEL 7 (and rebuilds) do at least mirror the journal output to syslog, so /var/log/messages and friends are still there, in plain text. I just verified this on my CentOS 7 evaluation server; yep, /var/log/messages and friends still there and still being used. As to systemd being a big binary, well, the typical initscript is being run by a binary also, even if it is somewhat smaller, and as shellshock shows that still has an attack surface. The systemd config files are much easier to understand than the typical initscript (and since the 'functions' most distributions provide are directly sourced, you need to include that code as well) is, by a very large margin. I'm not thrilled by this change, but after stepping back and looking over all the various systems I've dealt with over the last 25+ years it's honestly not as big of a change as some of the things I've seen (and my experiences include VMS and a number of Unix variants, including Xenix, Irix, SunOS/Solaris, and Domain/OS. And don't get me started on the various CLI's for various switch and router vendors, or I'll throw some Proteon gear your way.). And while I should be able to enjoy a better desktop experience (I have used Linux as my primary desktop for 17 years), I can also see the server-side uses for the systemd approach, most of which have to do with highly dynamic cloud-style systems (and I'm thinking private cloud, not public). I can see how being load-responsive and rapidly spinning up compute resources as needed and for only as long as needed could help reduce my cost of power; spread out to millions of servers (like Google or Facebook) and the energy savings could be very significant. Much like how package delivery companies plan routes to use only right-hand turns to save megabucks per year on fuel costs.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote: All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts. in FreeBSD, the bulk of the rc.d scripts are basically the same format, inhaling a standardized library of functions, populating some variables, maybe adding a few custom functions, then jumping to main. all largely driven off variables which have preset defaults in /etc/default/rc.conf, and over-ridden by /etc/rc.conf. something i saw in various linux systems, which i now see moving into FreeBSD, is the concept of the .d config directory, where the files in /etc/myapp.d are effectively concatenated to /etc/myapp.conf. this is quite nice from a sysadmin perspective, as you can set defaults in /etc/myapp.conf, and then over-ride them with server/environmental specific (and appropriately named) files in /etc/myapp.d/ --jim -- Jim Mercer Reptilian Research j...@reptiles.org+1 416 410-5633 He who dies with the most toys is nonetheless dead
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts. Set the location of the pid file, set the path of the executable, set the command line flags/options, maybe change some flags/options based on some options in another file like /etc/sysconfig/daemon_name (also shell commands which are just executed inline), then the start/stop/reload/restart/status case statements. And the dependencies of course. It really could just be config files like xinetd or logrotate except for a few hard cases where you could have a run this script attribute. Replacing run these scripts in the right order with a config-driven service manager sounds like a sensible development. (Not necessarily the One True Way, but certainly an option). Pulling complicated things like chroot, capabilities etc into one place, getting them right, and then letting services specify what they want, rather than everyone having to re-invent the same shell scripts sounds like it would encourage use of those features. I can even see some more advanced functionality to specify checks / frequencies for is this service still running / alive that effectively moves a lot of watchdog functionality into the service manager. I'm somewhat confused (without reading the implementation details, just conceptually) as to why the service manager is also providing DHCP client, SNTP client, virtual consoles, session management... I can completely understand why the do one thing crowd are taking objection to that. Regards, Tim.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
- Original Message - From: Lamar Owen lo...@pari.edu Speaking from my own experience, the actually relevant and package-specific guts of the typical initscript could be easily replaced by a simple text configuration that simply gives: 1.) What to start 2.) When to start it (traditional initscripts work on a linear timeline of priority slots; systemd units have more flexibility) 3.) How to start it (command line options) This should not need to be an executable script. This is what systemd brings to the table (Upstart brought some of this, too). That is a perfectly valid point. We don't dislike systemd because it does that. We dislike it because it doesn't *only* do that. Cheers, -- jr 'see also IPv6' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On 10/22/2014 03:51 PM, Barry Shein wrote: I wish I had a nickel for every time I started to implement something in bash/sh, used it a while, and quickly realized I needed something like perl and had to rewrite the whole thing. Barry, you've been around a long time, and these words are pearls of wisdom. This seems to be the reasoning behind replacing the spaghetti known as 'initscripts' currently written in sh with something written in a real programming language. Upstart and systemd are both responses to the inflexible spaghetti now lurking in the initscript system, of which the pile steaming in /etc/init.d is but a part. Sure, one can insist on charging forward in sh but at some point it becomes, as Ken Thompson so eloquently put it on another topic entirely, like kicking a dead whale down the beach. This seems to be the attitude of the systemd developers, although they're not as eloquent as Thompson in saying it. But I remember being just as abrasive, just on a smaller scale, myself... Now, I've read the arguments, and I am squarely in the 'do one thing and do it well' camp. But, let's turn that on its head, shall we? Why oh why do we want every single package to implement its own initscript and possibly do it poorly? Wouldn't it be a case of 'do one thing well' if one could do away with executable shell code in each individual package that is going to run as root? Wouldn't it be more 'do one thing well' if you had a 'super' inetd setup that can start services in a better way than with individually packaged (by different packagers in most cases) shell scripts that are going to run as root? Shouldn't the initialization logic, which is 'one thing that needs doing' be in one container and not thousands? Now, I say that having been a packager for a largish RPM package several years ago. I waded the morass of the various packages' initscripts; each packager was responsible for their own script, and it was a big mess with initscripts doing potentially dangerous things (mine included; to clear it up, I maintained the PostgreSQL packages for the PostgreSQL upstream project from 1999 to 2004). Ever since 1999 there have been issues with distributed initialization logic (that runs as *root* no less) under hundreds of different packagers' control. It was and is a kludge of the kludgiest sort. Having a single executable program interpret a thousand config files written by a hundred packagers is orders of magnitude better, security-wise, than having thousands of executable (as *root*) scripts written by hundreds of different packagers, in my experienced opinion. If anything, having all initialization executable code in one monolithic package very closely monitored by several developers (and, well, for this purpose 'developers with attitudes' might not be the worst thing in the world) is more secure. It *is* a smaller attack surface than the feeping creaturism found in the typical /etc/init.d directory. And Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit and its cousin /etc/rc.local. Now, as much as I dislike this magnitude of change, it seems to me that systemd actually is more inline with the traditional Unix philosophy than the current initialization system is. But I always reserve the right to be wrong. And I am definitely not fond of the attitudes of the various systemd developers; systemd assuredly has its shortcomings. But it *is* here to stay, at least in RHEL-land, for at least the next ten years. Having said that, if you want to use Upstart, by all means use Upstart; RHEL6 (and rebuilds) will have Upstart until 2020. So you're covered for quite a while yet, if you use CentOS, Scientific Linux, or another RHEL6 rebuild (or actual RHEL6). And for those who bugle that systemd will be the 'end of unix as we know it' I just have one thing to trumpet: Death of Internet Predicted. Film at Eleven.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
This is a good point, but it is perfectly possible to have a sysvinit system not written in shell scripts. I had rewritten most of the init system in python at one point for example. And its only been made easier to do over time now that #! Interpertation was moved kernelside. A system like this could solve all the problems of both sides since it is now a proper programming language so we can do more config style initscripts without the blob that is systemd. And for parallel init, you can do it in bash, iirc Gentoo does parallel init in bash. On Oct 23, 2014 1:45 PM, Lamar Owen lo...@pari.edu wrote: On 10/22/2014 03:51 PM, Barry Shein wrote: I wish I had a nickel for every time I started to implement something in bash/sh, used it a while, and quickly realized I needed something like perl and had to rewrite the whole thing. Barry, you've been around a long time, and these words are pearls of wisdom. This seems to be the reasoning behind replacing the spaghetti known as 'initscripts' currently written in sh with something written in a real programming language. Upstart and systemd are both responses to the inflexible spaghetti now lurking in the initscript system, of which the pile steaming in /etc/init.d is but a part. Sure, one can insist on charging forward in sh but at some point it becomes, as Ken Thompson so eloquently put it on another topic entirely, like kicking a dead whale down the beach. This seems to be the attitude of the systemd developers, although they're not as eloquent as Thompson in saying it. But I remember being just as abrasive, just on a smaller scale, myself... Now, I've read the arguments, and I am squarely in the 'do one thing and do it well' camp. But, let's turn that on its head, shall we? Why oh why do we want every single package to implement its own initscript and possibly do it poorly? Wouldn't it be a case of 'do one thing well' if one could do away with executable shell code in each individual package that is going to run as root? Wouldn't it be more 'do one thing well' if you had a 'super' inetd setup that can start services in a better way than with individually packaged (by different packagers in most cases) shell scripts that are going to run as root? Shouldn't the initialization logic, which is 'one thing that needs doing' be in one container and not thousands? Now, I say that having been a packager for a largish RPM package several years ago. I waded the morass of the various packages' initscripts; each packager was responsible for their own script, and it was a big mess with initscripts doing potentially dangerous things (mine included; to clear it up, I maintained the PostgreSQL packages for the PostgreSQL upstream project from 1999 to 2004). Ever since 1999 there have been issues with distributed initialization logic (that runs as *root* no less) under hundreds of different packagers' control. It was and is a kludge of the kludgiest sort. Having a single executable program interpret a thousand config files written by a hundred packagers is orders of magnitude better, security-wise, than having thousands of executable (as *root*) scripts written by hundreds of different packagers, in my experienced opinion. If anything, having all initialization executable code in one monolithic package very closely monitored by several developers (and, well, for this purpose 'developers with attitudes' might not be the worst thing in the world) is more secure. It *is* a smaller attack surface than the feeping creaturism found in the typical /etc/init.d directory. And Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit and its cousin /etc/rc.local. Now, as much as I dislike this magnitude of change, it seems to me that systemd actually is more inline with the traditional Unix philosophy than the current initialization system is. But I always reserve the right to be wrong. And I am definitely not fond of the attitudes of the various systemd developers; systemd assuredly has its shortcomings. But it *is* here to stay, at least in RHEL-land, for at least the next ten years. Having said that, if you want to use Upstart, by all means use Upstart; RHEL6 (and rebuilds) will have Upstart until 2020. So you're covered for quite a while yet, if you use CentOS, Scientific Linux, or another RHEL6 rebuild (or actual RHEL6). And for those who bugle that systemd will be the 'end of unix as we know it' I just have one thing to trumpet: Death of Internet Predicted. Film at Eleven.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said: Now, I've read the arguments, and I am squarely in the 'do one thing and do it well' camp. But, let's turn that on its head, shall we? Why oh why do we want every single package to implement its own initscript and possibly do it poorly? Umm.. because maybe, just maybe, the package maintainers know more about the ugly details of what it takes to start a given package than the init system authors know? If they botch the boilerplate section of an initscript, maybe they shouldn't be releasing packages. On the other hand, the *non*-boilerplate section of the initscript is something that *only* the package maintainers are qualified to write. pgpy6DpFXXIp5.pgp Description: PGP signature
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On 10/23/2014 02:22 PM, valdis.kletni...@vt.edu wrote: On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said: Now, I've read the arguments, and I am squarely in the 'do one thing and do it well' camp. But, let's turn that on its head, shall we? Why oh why do we want every single package to implement its own initscript and possibly do it poorly? Umm.. because maybe, just maybe, the package maintainers know more about the ugly details of what it takes to start a given package than the init system authors know? Speaking from my own experience, the actually relevant and package-specific guts of the typical initscript could be easily replaced by a simple text configuration that simply gives: 1.) What to start 2.) When to start it (traditional initscripts work on a linear timeline of priority slots; systemd units have more flexibility) 3.) How to start it (command line options) This should not need to be an executable script. This is what systemd brings to the table (Upstart brought some of this, too). It allows the packager to declare those details that the packager knows about the package and eliminates the boilerplate (that is different between versions of the same distribution; I for one maintained initscripts across multiple versions of multiple distributions, all of which had different boilerplate and different syntax). I should not have needed to learn all the different boilerplate, as that was a distraction from the real meat of packaging (it could be argued that the presence of syntactically arcane boilerplate is a problem in and of itself: as a for instance, the nice 'daemon' function most RPM-based distributions supply in /etc/init.d/functions works for some initscripts and not for others; PostgreSQL is one for which it doesn't work and it's not obvious at first glance why it doesn't); I should simply have been able to tell the init system in a declarative syntax that I needed to start the program '/usr/bin/postmaster' with the command line options for database directory and listening port (among some other items). And that includes 99% of what the various initscripts do (yeah, the PostgreSQL script of which I was one author did one thing that in hindsight should simply not have been in the initscript at all). Many of the 1% exceptions perhaps don't belong in code that is run as root every single time that particular daemon needs to start or stop. The perhaps 0.5% remaining that absolutely must be run before starting or stopping, well, yes, there should be an option in that declarative syntax to say, for instance, 'before starting /usr/bin/postmaster, check the version of the database and fail if it's older with a message to the log telling the admin they need to DUMP/RESTORE the database prior to trying to start again' .. (the systemd syntax does allow this). I have personally compared the current PostgreSQL systemd unit (/usr/lib/systemd/system/postgresql.service on my CentOS 7 system) to the old initscript. I wish it had been that simple years ago; the .service file is much cleaner, clearer, and easier to understand; no funky shell quote escapes needed. And it doesn't execute as root, nor does it source arcane boilerplate functions, the source of some of which will make your eyes bleed. And to do a customized version you just drop your edited copy in /etc/systemd/system/ and you're done, since it won't get overwritten when you update packages. When configuring Cisco IOS, we use a declarative syntax; the systemd .service file's syntax is as readable as the typical startup-confg is. Imagine if we used the typical bash initscript syntax to bring up interfaces and services on our routers.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On 10/23/2014 10:43 AM, Lamar Owen wrote: Wouldn't it be more 'do one thing well' if you had a 'super' inetd setup that can start services in a better way than with individually packaged (by different packagers in most cases) shell scripts that are going to run as root? inetd versus xinetd -- I thought that was an excellent change. It was closely targeted, well documented, and did indeed do one thing well: accept connections and pass them off to a handler. I'm not so sure about systemd yet. I've not tried to create a daemon of my own to run under the setup. I have tried to use upstart, and found the execution of upstart (CentOS 6) didn't match the documentation. Further, there was no here's how you go from sysvinit to upstart that made sense. I did see that systemd *does* have a paper for people needing to move from the old sysvinit to systemd, which is a plus on the surface. I'll be trying that in the future.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts. Set the location of the pid file, set the path of the executable, set the command line flags/options, maybe change some flags/options based on some options in another file like /etc/sysconfig/daemon_name (also shell commands which are just executed inline), then the start/stop/reload/restart/status case statements. And the dependencies of course. It really could just be config files like xinetd or logrotate except for a few hard cases where you could have a run this script attribute. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
