Announcement

Collapse
No announcement yet.

systemd 255 Released With A "Blue Screen of Death" For Linux Systems

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

  • gotar
    replied
    Originally posted by varikonniemi View Post
    No, i'm showing you how systemd is so complex, as was my first argument in this thread, that very very few people know how to use it. And usually end up wishing for the best or working around it, like here.
    Don't you get or just ignore that POSIX sh (the /bin/sh) is much more complex, and any orchestration using it is virtually impossible? The number of people capable of writing correct systemd unit is several orders of magnitude larger than the same using sh. Most sh scripts in the wild as a user-provided content contains serious mistakes. Many professional project have such bugs as well. I haven't seen properly written non-trivial sh code in years. Trying to write my own reveals more and more errors as time passes. It is much easier to write reliable code in perl, even so noone tries, because this programistic approach is simply inferior to declarative syntax.

    I gave examples, you haven't related. Thus I assume you're not capable of either, especially POSIX sh.

    And you still don't understand, that this problem here was unrelated to any systemd complexity, but dependency management, which in sh is much more intricate, up to the point that noone cares. There is no systemd-workaround here. Going SysV-way would be to remove the dependency on dbus entirely and hope for things not to break, and if (when) they do - just throw a bunch of `sleep 5` stanzas wherever this seems to mask the underlying issue.

    Leave a comment:


  • varikonniemi
    replied
    No, i'm showing you how systemd is so complex, as was my first argument in this thread, that very very few people know how to use it. And usually end up wishing for the best or working around it, like here.

    Leave a comment:


  • gotar
    replied
    Originally posted by varikonniemi View Post
    Since my previous answer did not satisfy you, now if you are fast you can show your superiority by going and teaching arch linux developers how to tell systemd that one unit replaces an older unit. Simple, right? They failed and took a bigger hammer with drawbacks into use instead.
    You seem to imply, that the init system entirely lacking dependencies is superior over a more sophisticated, because in the featured one there is a dependency problem when one of the dependencies is going to change during upgrade.

    This resembles "Windows XP is superior to Linux, because it just works, and under Linux you need to manage permissions and after su to root there's no X11 cookie and my program cannot run".

    such simplicity and elegance that manual hacking is REQUIRED. An init script would work by default.
    No - an init script doesn't have ANY reasonable way of specifying, checking or enforcing dependencies, as ANY level of hacking required to acomplish this reliably is insufficient.
    There is no such problem in SysV only because it's so hard to implement, that everyone gave up a long time ago.

    If you try to use the LSB headers for such dependency rename/replace (Required-Start: dbus-daemon) you'll fail miserably, as there are no logical operators (two optional "+" dependencies are still optional) nor any way to substitute one service for another ...unless you create some $dumb_dbus insserv, which is in principle the same as systemd solution, just more cumbersome.
    So basically in SysV world you have no choice over no dependencies at all, or even more "hackery".

    Once again you're comparing spear hunting with canned food, complaining about more sophisticated process needed (and refrigerators!)
    Last edited by gotar; 12 January 2024, 08:15 AM.

    Leave a comment:


  • varikonniemi
    replied
    Originally posted by gotar View Post

    Still waiting for your SysV script proving me wrong.



    Anything to back this statement up?



    Oh, they were surely experienced. Developers. Any link? I'm very curious about the problem details!
    Since my previous answer did not satisfy you, now if you are fast you can show your superiority by going and teaching arch linux developers how to tell systemd that one unit replaces an older unit. Simple, right? They failed and took a bigger hammer with drawbacks into use instead.



    Making dbus-units an empty package depending on dbus-broker-units and setting up replaces to install either dbus-broker-units or dbus-daemon-units on existing systems. This would avoid asking the user on a new installation, but I could not get the replaces to work properly.

    The status quo is that dbus-broker has to be installed and its services enabled manually.
    ‚Äč
    such simplicity and elegance that manual hacking is REQUIRED. An init script would work by default.
    Last edited by varikonniemi; 11 January 2024, 01:02 PM.

    Leave a comment:


  • 8-bit memories
    replied
    Originally posted by Barley9432 View Post
    You honestly have to love systemd. Their product is incredible. It shows what can be accomplished when people work together well.
    Embrace, extend, extinguish.

    Leave a comment:


  • varikonniemi
    replied
    i said non-trivial and correct. For instance the lnd autostart service i talked about earlier in my posts. Yes, it worked, it autostarted. But it was not correct, because it had to be done in a special way for systemd to communicate with the started process

    Leave a comment:


  • Mateus Felipe
    replied
    Originally posted by varikonniemi View Post
    SO MANY features get rolled into this project. New keywords for service files even when there already existed a whole bagful. Honestly, almost no-one knows how to correctly write a systemd service file that does exactly what is wanted. There are 5 methods to do the same thing, but they differ slightly in behavior in some edge case, and it usually takes a discussion thread of like 5 experienced systemd users and several days of brainstorming to achieve a "final" consensus how some non-trivial service file should be written. WTF?

    I managed pretty well to live with cron and shell scripts under sysV. With systemd i can only hope google brings me to the right discussion thread for the type of service i need...
    Wdym? I easily wrote a service to play the "blblblblbl a-hahah" part of Vita's 7th Element every round hour.

    Leave a comment:


  • unixguru
    replied
    One doesn't have to use systemd long at all to discover what a pile of absolute dogshit it is. I used it only briefly and still managed to encounter a major showstopper bug. When bootstrapping my distro from a Linux Mint system I accidentally double-mounted the virtual filesystems on my target volume. About one minute later systemd crashed and brought the whole system down, lol. Tried this a couple more times and even if I immediately unmounted the erroneous mountpoints systemd still crashed anyway a minute later. What does one expect from shitware written by the notorious goon Linux Puttering who has been terrorizing Linux with his buggy, shit code since the Pulseaudio days? Anyone who thinks that kind of garbage software belongs in Linux needs really needs to stick with Windows.

    Leave a comment:


  • unixguru
    replied
    1. you have no experience in SysV - distro developers (including me) do,
    1. I'm a distro developer, gotard--and my distro is way better than your junkware.Your arguments are nonsensical and ridiculous.

    2. you have no sh nor systemd insigths (like actual codepath analysis, debugging) - distro and systemd developers do,
    Codepath analysis? Debugging? That's what systemd chodes have to do, because their system is amazingly overcomplicated and buggy. Never found that necessary with simple, basic bash init scripts.

    3. you have only small subset of experiences of your own systems - while developers were solving with many user-provided cases, some of which are hard to even imagine,
    The entire point of init scripts is that they can be customized by the sysadmin for their own system rather than one all powerful centralized code repository that has to imagine and write code for every possible use case.

    4. you still ignore the fact, that you can start SysV script using systemd (even after obsoleting native support, you can use it directly in short unit glue)
    Why the hell would I want to use the giant, bloated, shitware monstrosity like SystemD to start anything? I have self respect, and standards.

    and yet you still think, that you know better?
    Clearly he does. Many of us do, obviously.

    Wow, this looks like this famous gen-Z self-esteem.
    Nope, it looks more like you're a) dumber than a sack of dog shit, b) have zero self respect, or c) are paid to spew this garbage.

    You can still prove me wrong
    You've already proved yourself wrong long ago; the only thing you are trying to do is drag more and more noobs into your hell of wrongness.

    Leave a comment:


  • gotar
    replied
    Originally posted by varikonniemi View Post
    sorry i don't know, there are some 145 bug reports concerning systemd in the lnd project, in one of them it was found the issue was not in lnd but in the systemd unit file keyword interaction being completely opaque, and if my memory serves me right, also undocumented?
    What kind of argument is that? TL;DR: I've linked some patches and would like you to discuss them.

    Of course there are and always will be code and documentation issues in all the non-trivial projects. That's why there are bug trackers and mailling lists.
    Recently I spend some time with ixgbe cards stopped working and the debug code has to be added to the Linux kernel.

    You think it is amusing to upgrade your server just to loose networking? It's not - but that's what sysadms do. Researching, bisecting, debugging, reporting, discussing, testing patches. We don't run around screaming "Linux sux, my NIC is broken since 6.2 (yes, it was actually broken for 10 months and the fix is scheduled for 6.8), going back to *BSD".
    Yet for systemd you seem to propose entirely different standard - "some guys who knows how long before had some problems, never bothered with details, but this proves that systemd sux".

    Compare some vague "keyword interaction" with this piece of code - it took me many hours to debug this pdksh, mksh and bash behaviour (when called as /bin/sh); at this time (it was 11 years ago and I still remember this) I wasn't considering dash.

    Try to find any source or any documentation regarding this issue. Any rationale in POSIX, for either being consistend or allowing such discrepancy.

    Do you really think that self-contained code of systemd is harder to analyze, in the lack of documentation (yes, I also did that), than hundreds of millions lines of code spread across dozens of projects, which are required by SysV scripts?

    Ever tried to analyze bash sources? This becomes funny very quick - as soon as you reach some pre-2018 code, the commit messages are totaly useless. "Bash-4.4 patch 19" - wow, thats helpful! I don't understand "power"-using bash anyway, when there's supreme zsh.

    To summarize:
    1. you have no experience in SysV - distro developers (including me) do,
    2. you have no sh nor systemd insigths (like actual codepath analysis, debugging) - distro and systemd developers do,
    3. you have only small subset of experiences of your own systems - while developers were solving with many user-provided cases, some of which are hard to even imagine,
    4. you still ignore the fact, that you can start SysV script using systemd (even after obsoleting native support, you can use it directly in short unit glue)
    and yet you still think, that you know better?

    Wow, this looks like this famous gen-Z self-esteem. I personally wouldn't dare going with such statements, if I hadn't had doing this (system management) for the most of my 25+ years in Linux and havent't actually seen and debug all the code we're taking here about.

    You can still prove me wrong - just provide the SysV script I was asking or analyze the background subshell locking issue I've linked above.

    Leave a comment:

Working...
X