Announcement

Collapse
No announcement yet.

Systemd In Ten Years Has Redefined The Linux Landscape

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • k1e0x
    replied
    I had been working with launchd some and where as I don't like it really.. if Linux decided to use it, I wouldn't have as much of a problem with that as I do systemd because it has a limited scope. The problem is actually much larger than systemd itself though.. it is that Linus' Unix being controlled by powerful corporate companies has lost all reverence for history. It has no overall direction other than the goal of RedHat (IBM) corporate server dominance and vendor lockin.

    I've been looking at the development of a new Unix like system Redox, and it's really refreshing to see they are able to look at other systems and do seem to be taking the right approach. https://youtu.be/G4VlHzyKZeE?t=798

    Leave a comment:


  • k1e0x
    replied
    Originally posted by Britoid View Post

    OpenRC does maybe 5% of what systemd does.
    *should* do.
    Ironically systemd also does about 5% of what it should do.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by oiaohm View Post
    This is something those anti-systemd people never do is see the time line to see that many people were in fact upset with sysvinit there have been 5 different groups who know what they are doing who have been upset with it. Like it or not change had to happen. If you don't like systemd you really do need to be coding on openrc or some new solution using cgroupv2 and pidfd that works the way you want.
    I was there during this entire timeline.. and I can see that just fine that it's a strawman. (maybe you believe this is true, who knows) I don't like sysvinit, nor do I like systemd. Just because one is bad doesn't mean the other is good.

    Perhaps we can reconcile some of the systemd hate here.. It's the holidays. I simply believe it was the wrong choice. OpenRC is the correct approach. (or other highly functional, modern limited scope init, I'm not solely sold on one thing)

    The problem with systemd is the same problem with btrfs (not to start another flame up)
    Too much code was written too fast without any direction or scope. That is a plague in Linux with it's popularity now.

    Originally posted by pkese View Post
    Thanks to whomever posted the link to https://www.youtube.com/watch?v=o_AIw9bGogo
    It is a great and unbiased (FreeBSD perspective) look at systemd.
    This is his own opinion. FreeBSD may get a new init system, and no.. that wouldn't be bad.. but you can be assured that it will look nothing like systemd.. again.. OpenRC was already ported to FreeBSD and is used by default for TrueOS, GhostBSD, Project Trident and others. (Possibly FreeNAS uses it too) FreeBSD takes a lot of time and care when implementing stuff.. they do so from a "entire OS" engineering perspective. It isn't various companies trying to one up eachother.

    Also OpenRC was originally a NetBSD thing anyhow before Gentoo started using it..
    Last edited by k1e0x; 20 December 2019, 04:43 PM.

    Leave a comment:


  • Britoid
    replied
    Originally posted by k1e0x View Post
    No hate here.. but I just believe it was the wrong choice for Linux. It caused me to stop using Linux personally and focus on FreeBSD as an alternative. (and I'd been a full time linux user since 1994) All my personal servers were running FreeBSD by 2012, something I don't regret.

    I think OpenRC does 99% of what systemd does/should do and it's clearly just a simple init system. This was the right choice and they missed it.. It almost reminds me or Apple Pink/Blue.. where every idea is valid and ok because the project has no scope.
    OpenRC does maybe 5% of what systemd does.

    Leave a comment:


  • Britoid
    replied
    Originally posted by Farmer View Post

    You put more effort in typing that post than was spent in messing with a setup. That's quite an achievement. You get a participation trophy.

    :>systemctl enable mariadb.service
    ok
    :>systemctl start mariadb.service
    ok
    :>systemctl enable nfs-server.service
    ok
    :>systemctl start nfs-server.service
    ok
    :>systemctl enable httpd.service
    ok
    :>systemctl start httpd.service
    ok


    reboot. No database or NFS. Httpd running fine.

    :>systemctl enable mariadb.service
    "Your spell still has no effect."
    :>systemctl enable nfs-server.service
    "Your spell still has no effect."
    :>systemctl start mariadb.service
    ok
    :>systemctl start nfs-server.service
    ok
    :>systemctl restart httpd.service
    ok

    * When systemctl enable httpd works
    * But systemctl enable mariadb and systemctl enable nfs-server don't.
    * But they start fine manually.
    * The software is borked. Fanbois opinions not withstanding.

    I'd write a bash script and hit that when the machine starts but I'd have to care more. I'd spend the time to figure out what's wrong but I'd also have to care more. Some of you missed the point. It works more poorly than the predecessors. That I refuse to spend the time and effort tracking it down notwithstanding. Much less effort just to start them on boot manually.

    I do work on my computer. Instead of work on my computer. Whenever possible.


    If that is true that is almost certainly down to misconfigured units then anything actually wrong with systemd itself. systemd is used in mission critical envrionments (as part of RHEL), so I doubt a bug like that would exist in systemd itself.

    Leave a comment:


  • k1e0x
    replied
    No hate here.. but I just believe it was the wrong choice for Linux. It caused me to stop using Linux personally and focus on FreeBSD as an alternative. (and I'd been a full time linux user since 1994) All my personal servers were running FreeBSD by 2012, something I don't regret.

    I think OpenRC does 99% of what systemd does/should do and it's clearly just a simple init system. This was the right choice and they missed it.. It almost reminds me or Apple Pink/Blue.. where every idea is valid and ok because the project has no scope.
    Last edited by k1e0x; 20 December 2019, 04:18 PM.

    Leave a comment:


  • aht0
    replied
    Originally posted by Hibbelharry View Post

    That's not what happened. They looked around. They for instance had a look at Apple's launchd..
    They obviously didn't look beyond launchd or were blinded by NIH syndrome. Or were very afraid to actually find something.
    Fuckin' article is 8 years old. By then, daemontools had been around over a decade. And it's not the only of it's kind either..
    https://isotope11.com/blog/manage-yo...th-daemontools

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Farmer View Post
    You put more effort in typing that post than was spent in messing with a setup. That's quite an achievement. You get a participation trophy.

    :>systemctl enable mariadb.service
    ok
    :>systemctl start mariadb.service
    ok
    :>systemctl enable nfs-server.service
    ok
    :>systemctl start nfs-server.service
    ok
    :>systemctl enable httpd.service
    ok
    :>systemctl start httpd.service
    ok


    reboot. No database or NFS. Httpd running fine.

    :>systemctl enable mariadb.service
    "Your spell still has no effect."
    :>systemctl enable nfs-server.service
    "Your spell still has no effect."
    :>systemctl start mariadb.service
    ok
    :>systemctl start nfs-server.service
    ok
    :>systemctl restart httpd.service
    ok

    * When systemctl enable httpd works
    * But systemctl enable mariadb and systemctl enable nfs-server don't.
    * But they start fine manually.
    * The software is borked. Fanbois opinions not withstanding.

    I'd write a bash script and hit that when the machine starts but I'd have to care more. I'd spend the time to figure out what's wrong but I'd also have to care more. Some of you missed the point. It works more poorly than the predecessors. That I refuse to spend the time and effort tracking it down notwithstanding. Much less effort just to start them on boot manually.

    I do work on my computer. Instead of work on my computer. Whenever possible.
    Welcome novice stop blaming systemd for you problems. Be thankful for it.

    This totally reads like a total novice screwup.
    https://dev.mysql.com/doc/refman/8.0...sk-issues.html
    One its not recommend to have mariadb or mysql on nfs share.

    I don't see you checking you systemctl for a failure status information. I would suspect that nfs-server is failing because the network it need is not starting up.

    Starting manually is starting after the networking and everything is up. Could be that network manager is only like connecting your wifi network after you are logged in. Setting mistakes or lack of settings cause these problems even with the older sysvinit systems.

    Please note I have had nfs-server not start when using sysvinit systems for the same kind of reasons. I have also had the case where mariadb fails to start on a sysvinit system on system start up then will not start manually at all. Why a process has leaked and its now locked a file so mariadb cannot start. Systemd cgroups around services means if a service fails to start properly it in fact stops it all so you can manually start it latter without issue. Basically since systemd did that for you and you don't thank systemd that you can even start the service manually latter instead want to blame it for your problems.

    "systemctl start nfs-server.service" << this manual line of yours may not have been required.

    I guess you did not run systemctl between commands to see what was started. Systemd can be quite smart you ask for "systemctl start mariadb.service" it sees attempted access to where nfs share should be and auto attempts "systemctl start nfs-server.service" since it was enabled but failed before. So systemd will allow you do things out of order to address problems at times.

    Exactly why were doing the "systemctl enable mariadb.service" lines when something had started before doing a "systemctl" to see the status of your services. If they are listed they are already enabled.

    More useful of course would have been "systemctl status mariadb.service" and "systemctl status nfs-server.service" yes you had status check options under sysvinit and you had to use them as well.

    I would not say the software is borked in this case the "Problem Exists Between the Keyboard And the Chair." The PEBKAC wants to blame systemd instead of admit its a configuration error that can happen with any init/service management system that has to be diagnosed leading to a configuration alteration that needs to be done.

    I see this a lot lets blame systemd instead of having to learn how todo stuff properly.

    PS you can alter system with systemd that the http server does not come up unless the database server is started as well to prevent those accessing site getting access to a webpage in broken state due to missing database. This can be highly important at times with login databases.
    Last edited by oiaohm; 20 December 2019, 03:49 PM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ALRBP View Post
    That said, the thing I really do not like with systemd is the idea to put in one big software things that should be independent.
    systemd is a project composed by many daemons

    What's next, complaining that "coreutils" (aka GNU command line tools) are one big software?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Farmer View Post
    30 years ago I was able to stick stuff in autoexec.bat and it started automatically when the computer booted.
    20 years ago I moved to Linux and figured out the init system. Put stuff in there and it started automatically when the computer booted.
    Today after my computer starts I get to manually start the database server and NFS. Then restart the web server.
    Really I don't know what you are doing wrong here. I have systemd start everything I need. Thinking systemd has sysvinit emulator so everything you did with sysvinit still works with systemd.

    Originally posted by Farmer View Post
    No, systemd hasn't made my life better. The old init system worked, systemd doesn't.
    This is not fact that the old system init worked.

    Lets do a corrected timeline without personal bias crap.

    System V Unix appears 1983
    1992 sysvinit appears for Linux what is basically reimplemention of a system that is 9 years old at this point. It was not designed for Linux either. http://git.savannah.nongnu.org/cgit/.../doc/Changelog
    Yes sysvinit was design for a Minix kenrel. Yes Minix does handle PID/processes different to a Linux kernel.
    All your early Linux distributions pick up and modify sysvinit because this is simpler than coding something that in fact works. Partly due to missing kernel features and bugs in way Linus implemented process handling making something that in fact works at this point is impossible and stays this way for a darn long time.

    2001 daemontools appears because there is issues with service management. The defects at kernel level means this can never work exactly right on Linux at this stage it works well on freebsd and minix.

    2004 Runit appears attempting to fix sysvinit defects using daemontools methods. Yes still still stuffed.

    2005 Initng appears most distributions switch to this to fix the sysvinit single threaded start up and shutdown problem. This end up merged back into sysvinit by 2007. This has not fixed the process management problem in fact has made the race condition risk worse.

    2006 Upstart appears attempting to fix problem with sysvinit and other init systems for Linux by using ptrace to track what processes service in fact started this fails hard. Yes upstart was picked up by majority of distributions before systemd appears.

    2007 Cgroup feature that will come known as Cgroup v1. This provides another option to track processes that would not have the nightmares of ptrace.

    2008 Openrc appears attempting to fix the problems with sysvinit and other init systems for Linux. Developers having a hard time getting anywhere to these developers cgroups v1 is appearing not to work right so they keep on back way from use it early on. Still suffering from once bitten twice shy problem over cgroups.

    2010 Systemd appears with a developer willing to go all out to address the sysvinit problem even if it causes hell.

    2013 Systemd is picked by distributions So yes 20 years latter compare to when we started using sysvinit. Note we are over a decade in to attempt to fix service management/sysvinit with failure after failure at achieving this goal.

    2016 Cgroup v2 appears because from systemd usage of cgroup v1 its absolutely clear past any question in design is broken as cgroup v1 can completely lock up system. At this point the Linux kernel now has enough to finally be able to track what a service has in fact started safely as long as you use cgroupv2. Something you could do in Minix this complete time from 1987 in fact due to different process table implementation.

    But there is still a problem. Killing processes are bring out a race condition in Linux and does under Minux as well. This problem is coming from the Posix standard so all Unix and related OS problem.

    2019 we finally get pidfd for Linux https://lwn.net/Articles/794707/ at long last you can kill exactly the right process under Linux all the time.

    So its taken 28 years ie 1991 to 2019 to get the Linux kernel to the point that the kernel provides all the features to write a init/service management system that works properly may be possible. Its going to take into next year for systemd to get pidfd usage in and another year for it to be in all common distributions. So 30 years to get at least 1 init/service management solution that technically works with the Linux kernel. Please note this is if pidfd does not turn out to be another cgroup v1 and have to be reworked. Fingers crossed we have made it finally to a functional kernel.

    The foundations are now in place to make init/service management systems that may fact work properly on Linux instead of the broken crap we have had up until now.

    This is something those anti-systemd people never do is see the time line to see that many people were in fact upset with sysvinit there have been 5 different groups who know what they are doing who have been upset with it. Like it or not change had to happen. If you don't like systemd you really do need to be coding on openrc or some new solution using cgroupv2 and pidfd that works the way you want.

    Leave a comment:

Working...
X