Language:
switch to room list switch to menu My folders
Go to page: First ... 26 27 28 29 [30] 31 32
[#] 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]

Agreed.



[#] 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

[#] Wed Aug 23 2017 12:05:45 EDT from Ragnar Danneskjold @ Uncensored

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

I'd have more problems with OSX if it weren't geared towards the desktop....
It's pretty rare you need to get that deep into the system.

[#] Fri Aug 25 2017 20:07:19 EDT from fleeb @ Uncensored

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

2017-08-18 11:22 from LoanShark @uncnsrd

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.


[Service]
Type=forking
PIDFile=[path to your PID file]
[...]

If your service creates a PID file, systemd will use the file specified by PIDFile to track whether or not the service is actually running, rather than trying to chase forks in a daemonizing process.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html

So, if your service can be told to create a PID file, that should help significantly.

If not... well, I dunno how you dealt with it in sysvinit.

[#] Sat Aug 26 2017 19:06:12 EDT from IGnatius T Foobar @ Uncensored

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

And that's why I'd love it if systemd became universal, at least for Linux ... instead of all the tedious mucking about with pid files, you could just run the program without forking into the background, systemd will spawn the process directly and can respond to it exiting.



[#] Sun Aug 27 2017 23:22:45 EDT from LoanShark @ Uncensored

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


It's universal enough though, right? It's now the default on both Ubuntu and RedHat-derived systems.

[#] Mon Aug 28 2017 12:13:27 EDT from fleeb @ Uncensored

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


Honestly, if I didn't have to deal with older distributions, I'd stop doing the whole daemonization thing and just run it as you might run any command on a command line.

Hrm... although, honestly, I could do both. I could take a command line argument that would daemonize if needed...

[#] Mon Aug 28 2017 13:34:59 EDT from IGnatius T Foobar @ Uncensored

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

It's universal enough though, right? It's now the default on both
Ubuntu and RedHat-derived systems.

Hmm. According to https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception it has been the default on CentOS, Debian, Fedora, Mint, SuSE, Red Hat, and Ubuntu for some time now (plus some others that I'm not counting as anything other than fringe players).

The question of course is: "as a software distributor, should I write exclusively to systemd?" I'm starting to think the answer is "yes" because anyone still running sysvinit in 2017 is probably already dealing with being a fringe player.

[#] Wed Aug 30 2017 10:54:47 EDT from fleeb @ Uncensored

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


Heh... well, I'm having to deal with ancient distributions, so I still have to write for sysvinit, upstart, and pretty much anything else.

Detecting which init tool the distribution uses is a new kind of entertainment.
In the sense that amputation of major limbs is entertaining.

[#] Thu Aug 31 2017 14:30:48 EDT from IGnatius T Foobar @ Uncensored

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

Right, and that's supposedly why every init-replacement at least *tries* to support sysvinit scripts. But it still feels sort of emulated and second-class.


Go to page: First ... 26 27 28 29 [30] 31 32