switch to room list switch to menu My folders
Go to page: First ... 121 122 123 124 [125]
[#] Tue Aug 01 2017 11:24:49 EDT from Ragnar Danneskjold @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

systemd, upstart, init....

Personally I'm with the Boycott Systemd folks - it goes against basic Unix philosophy.

[#] Tue Aug 01 2017 12:36:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Looks like that horse has left the barn.

Things don't seem to be working the way I expect, but maybe my expectations are wrong. I have to read up and test a bit more.

[#] Tue Aug 01 2017 15:44:59 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I suppose it's unsurprising that some of systemd's APIs have Haskell bindings... *vomit*

[#] Tue Aug 01 2017 17:42:55 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've been pretty happy with systemd, but it is true that systemd (like upstart, which fortunately is dying, and launchd, which unfortunately is not) is somewhat less "unix-like" than sysvinit.

The thing about systemd is that it *has* an API. And to install a service you only have to create a single unit file, and then make an API call (or just run the equivalent command from a shell script) to activate it. sysvinit is more understandable from a traditional unix perspective, but unfortunately it's a mess.

Of course, I never really liked init scripts to begin with. /etc/rc was better. (Yes I know slackware and BSD still use /etc/rc and I don't care.)

[#] Tue Aug 01 2017 18:05:27 EDT from Ragnar Danneskjold @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Binary logs? Blech.

[#] Wed Aug 02 2017 02:25:48 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Contrary to historical indications, the 'd' in systemd does not stand for daemon. It stands for disease.

[#] Wed Aug 02 2017 11:48:58 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, as I understand things (with my horribly Windows-esque background), sysvinit has this terrible problem where the scripts cannot be started concurrently.
So, we have two attempts, so far, to create something that can sanely start these services, yet still feel 'unixy-enough' to please people... and I guess from what I'm reading here, they both fail.

I think I prefer systemd to upstart... it feels more featureful, and I think it's slightly easier to write configuration files for it than upstartd (maybe because it's better documented? I forget).

I know that I've had to write scripts for installations that account for all three systems, and systemd felt more mature than upstart in this regard.

I think another problem I experience with sysvinit involves the many variations per distribution of linux of any kind of helper script to get things running.
Basically, if you're trying to write something that can be installed on Redhat, Debian, and variants of these, sysvinit risks introducing a lot of pain unless you build the entire thing from scratch without any assisting batch scripts.... and if you do that, you might miss some special thing that the distribution does that helps inform the user of some detail or something.

Or, putting all of this more concisely, the initialization of services in Linux is very problematic without *something*, while Windows (much as I hate it) with its SCM seems to have happened upon a fairly (for Windows) elegant solution. It'd be nice if someone could figure out something for Linux that felt right for posix-oriented OSes.

[#] Thu Aug 03 2017 17:48:21 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

the point about mission creep might be valid; I don't really know why they decide to make another logging service where we already had syslog.

[#] Fri Aug 04 2017 00:34:05 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That is a bullshido response if I'd ever seen one. Systemd is a total slap in the face, and completely ignores a TON of prior art in improving or even replacing sysvinit with alternatives that work as well, while retaining the Unix-y flavor.

BTW, Windows has a ton of supporting "batch" scripts as well (MS Installer anyone? OK, they're not literally .BAT files, but they do the same job) which gets executed upon installation or removal of a program. The only benefit to Windows is that you have one, and exactly one, precise directory layout.
But this is a solved problem in Linux, and has been for years.

Meanwhile, systemd seems to be a literal breeding ground for CVEs and bugs (DNS daemon that can't handle dashes? Sure. Why not?)

Systemd works great until it doesn't, then you're left in a world of pain and suffering. For cloud deployments, which is where systemd really shines, it works great because you have (like Windows) consistent system configurations.
But for anything else, it's a catagorical mistake.

[#] Fri Aug 04 2017 00:40:12 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

OK, that's perhaps a bit harsh on my part, but it burns me UP when I see revisionist defense of crapware. For example, numerous init replacements had already existed when systemd was first introduced which relied on multiprocessing for concurrently launching daemons and the like. One was even so simple that it basically relied on make (via make -j) to perform its system startup.

The only reason that systemd took hold in the industry is, quite frankly, it's a Red Hat product. And RH is popular in Enterprises around the globe (in one form or another). All the other, and more technically appropriate/superior solutions, were offered as one-off projects as your typical open source fare, hoping teh Bazaar style of project management would take hold and let projects become self-sustaining.

[#] Fri Aug 04 2017 07:15:03 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

MS Installer packages are little databases that you access with a limited Structured Query Language. Describing them as a script file is ... not accurate.

Windows has an SCM for services. It has been this way since NT (I can't recall if the 9x systems had it as well, but I know it's been around since NT 3.5). And while it's a bit heavy handed in some ways, it's a standard that you can mostly rely upon when working with Windows.

Linux has... kind of a mess. At least, from my perspective, as someone having to craft a debian package to install a product on an ungodly number of distributions of linux, with relatively limited resources. I have to be able to install this closed-source tool on 10-year old distributions of linux, and account for the different init styles so it fits in properly with that distributions best practices... such as they are/were. Add to this that I haven't had to do this before this job, and you'll see that I'm approaching this topic from a perspective free of opinions about any history of these systems, or even the degree to which something 'fits in' with the 'feel' of linux, since unfortunately my career has been dominated by working with Windows.

So, yeah... I'm more interested in accomplishing something specific. I don't care about the politics or history, just getting shit done. And I have to deal with every fucking variation of these damned init systems (even the fucking older versions, which occasionally couldn't handle something properly... like a binary that does the correct approach to turning into a daemon of all the most ridiculous and stupid things).

And so, I found systemd easier... because nobody has released a version of it in a distribution of linux made publically available that fails to work with an executable that turns itself into a daemon. Unlike upstart.

This said, I'm not suggesting it's a great system. To me, it feels like linux simply hasn't managed to find and settle on something that really works for it, so they're making do with systemd until someone comes up with The Right Thing.

Because at the end of the day, sysvinit sucks even worse than either upstart or systemd, if you want your OS to start in a snappy way.

[#] Mon Aug 07 2017 13:18:11 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

What about launchd? Does the "not unix like" design requirement apply to Apple or are they too far off the reservation already?

Like most old-skool unixheads, I am partial to SysV Init, but I've never liked the way init scripts are built. All those silly files and symlinks are a nuisance. I would have liked it if inittab had been expanded for scripts the way every other configuration file was: just have /etc/inittabs.d/ and a package maintainer can drop files in for startup, shutdown, etc.

As for systemd ... I didn't think it was necessary but it doesn't bother me enough to dwell on it for a long time. And you guys know that I am the kind of person who *will* do that.

[#] Tue Aug 08 2017 12:15:17 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

They're way off the reservation, but a lot of this systemd/upstart/no-shell stuff could be viewed as the rest of the industry playing catchup to NeXT/Apple

[#] Tue Aug 08 2017 14:09:22 EDT from bennabiy @ Uncensored

Subject: Reservation..

[Reply] [ReplyQuoted] [Headers] [Print]

So would that be the reservation expanding its tent-pegs?

[#] Thu Aug 17 2017 10:43:47 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: Reservation..

[Reply] [ReplyQuoted] [Headers] [Print]

That's kind of what I'm getting at here. At times, making something "unix-like" can be at odds with making it maintainable by non-gurus. Is it ok when Apple does it but not ok when Red Hat or Ubuntu does it? People have been trying to get the best of both worlds for decades (remember linuxconf?)

[#] Thu Aug 17 2017 17:05:40 EDT from bennabiy @ Uncensored

Subject: Re: Reservation..

[Reply] [ReplyQuoted] [Headers] [Print]


[#] Fri Aug 18 2017 10:29:18 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: Reservation..

[Reply] [ReplyQuoted] [Headers] [Print]

I was hoping for some thoughts from Ragnar, who is a fan of both the Apple system *and* the "unix-like" way of doing things. Clearly they are at odds with each other. Was it ok for Apple to break from tradition, but only Apple because they serve a different area of computing than, say, RedHat or Debian?

[#] Fri Aug 18 2017 11:22:42 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Back on that topic, I think I solved my systemd problem. Basically, systemd thinks it knows whether your service is running or not; it can be wrong. If your service was invoked directly from the init script, it doesn't know it's running when it is; if the start script fails, systemd will think it's running when it isn't; if the stop script fails, it may think it's not running when it is. Etc. In either of those states, the "stop" or "start" command may do nothing at all, by itself, because systemd thinks there's no state transition that needs to happen.

It's all a bit boneheaded, but there are ways to deal with it.

[#] Fri Aug 18 2017 18:24:08 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Do you control the start script or is it third party software? What I've found is that a lot of systemd start scripts are built as naive ports of sysvinit scripts -- maybe they were even auto-converted -- and they don't really take advantage of systemd.

Specifically: the script will have a start command, a stop command, and monitoring instructions, and the service still runs in the background, because that's how it was done under sysvinit. But if you instead write the script to have systemd start the service in the *foreground* then there's nothing to monitor.
When the service exits, either normally or abnormally, the kernel reliably tells systemd that the process ended; there's nothing to detect.

Obviously I loved this when I saw it because I used to have a habit of running services directly out of /etc/inittab this way, and was very frustrated when I couldn't rely on /etc/inittab being available anymore.

[#] Sat Aug 19 2017 02:31:08 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, it works either way. Your service can fork itself into the background... usually (though as pointed out in my last message, not always) systemd will be able to track its status in the background via cgroups.

sysvinit scripts are directly supported, and that's what we're using (and it's our script, at this point.) What I did was make the "stop" command try a little harder if its first attempt to stop the service gracefully fails, it will kill -9

Go to page: First ... 121 122 123 124 [125]