Jump to content

Photo

My 2 cents on systemd

systemd opinion

88 replies to this topic

#81
nrc

nrc

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts
  • LocationColumbus, Ohio, USA

There would seem to an issue with fragmentation of our userbase. This will only get worse. It would be nice to abstract daemon installation in some portable way.

Maybe some application that could convert from some universal configuration to whatever the local init system requires, or perhaps we should accept that systemd will be prevalent and make a converter that converts systemd configurations to openrc scripts? Does such a think already exist?

More about me at https://eddon.systems

 

It seems like it would be pretty easy to write a generic init script that would use unit files like configuration files.   Call it unitrc.  Then making a unit file work for start up would just be:

ln -s /etc/init.d/unitrc /etc/init.d/myservice
mv /usr/lib/systemd/system/myservice.service /etc/conf.d/myservice
rc-update add myservice 

Note that systemd's service startup information is stored in /usr.  Another example of the perversity of systemd. 



#82
uudruid74

uudruid74

    Advanced Member

  • Members
  • PipPipPip
  • 134 posts
  • LocationDallas, TX USA


It seems like it would be pretty easy to write a generic init script that would use unit files like configuration files. Call it unitrc. Then making a unit file work for start up would just be:

ln -s /etc/init.d/unitrc /etc/init.d/myservice
mv /usr/lib/systemd/system/myservice.service /etc/conf.d/myservice
rc-update add myservice 
Note that systemd's service startup information is stored in /usr. Another example of the perversity of systemd.

Or modify rc-update to look for systemd unit files?

More about me at https://eddon.systems

https://github.com/u.../bashTheObjects -- Object Oriented Programming in BASH !!
https://eddon.systems -- Stuff I'm Working on.


#83
adcdam

adcdam

    Advanced Member

  • Members
  • PipPipPip
  • 100 posts

I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.


  • nrc and iwoloschin like this

#84
uudruid74

uudruid74

    Advanced Member

  • Members
  • PipPipPip
  • 134 posts
  • LocationDallas, TX USA

I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.

It doubt it will ever be an option, let alone the default.

https://github.com/u.../bashTheObjects -- Object Oriented Programming in BASH !!
https://eddon.systems -- Stuff I'm Working on.


#85
nrc

nrc

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts
  • LocationColumbus, Ohio, USA

I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.

 
Unfortunately a lot of people have bought into the misinformation that you can't have a modern Linux distro without systemd.    Spread the word. http://without-systemd.org/


  • uudruid74 likes this

#86
uudruid74

uudruid74

    Advanced Member

  • Members
  • PipPipPip
  • 134 posts
  • LocationDallas, TX USA

Unfortunately a lot of people have bought into the misinformation that you can't have a modern Linux distro without systemd. Spread the word. http://without-systemd.org/

I'm not really a fan of udisks either. Even after unmounting/ejecting a usb device, I can't fsck the thing because the kernel thinks its in use, even with no files open on it. I think this is a udisks issue, which is now a systemd thing. The workaround is to remove the device and reinsert it but don't open it or else udisks will hang on to it forever.

These over-complicated system daemons are horrible. And they all seem to come from freedesktop.org ... I'm really starting to hate freedesktop.org.





More about me at https://eddon.systems

https://github.com/u.../bashTheObjects -- Object Oriented Programming in BASH !!
https://eddon.systems -- Stuff I'm Working on.


#87
uudruid74

uudruid74

    Advanced Member

  • Members
  • PipPipPip
  • 134 posts
  • LocationDallas, TX USA

There was a slashdot article about Busybox removing systemd support, which turned into an sub-thread about an ipv6 over ipv4 service.  The systemd maintainers added a respawn "fix" that would restart the service within 10 seconds since the daemon would abort if the network wasn't up .... of course this means that the upstream service providers get hit with retries every 10 seconds if your password is wrong or something else is misconfigured, and they were annoyed that the warning NOT to respawn wasn't being acknowledged and no notification was given that the unit file was being changed.  They site systemd as the problem for not verifying that the network is up before starting the service.  The systemd folks site that this shouldn't be necessary since "modern" systems (he mentions his Apple Powerbook) have intermittent networking and the daemon should use exponential backoff if the network is down.   The daemon author says people need to read the logs before restarting the daemon and the systemd guys say that users aren't admins and don't read logs!

 

This is a classic example of what I see as the division of thought.  The old-school admins see a server and classic start-up routines - you are started when networking comes up. If networking is down, abort.  Read the logs.  Auto-restart is bad.  Systemd wants it easy and wants it to work on a laptop without thought (and apparently without a GUI tool that checks the log to decide if it should respawn), wants services to be restarted and says that the daemon author doesn't provide an exit code as to why the daemon stopped, so the only choice is to restart for all exits.  He says the daemon is bi-polar because it will retry if the network is up when its started, but not other times, and sites network connectivity problems may not be local.

 

Here's my take on this.  Network down and can't connect are two different things.   The former is a local issues and easy to detect.  In this instance, the daemon can/should quit and log.  Further, networking should be UP before the daemon is started.  Specifically, the daemon should be started as a response to the "event" that the network is up.  If there is a login problem or other issue, it should also abort and log.   If the network is up, but you can't connect to the server, then use exponential backoff and retry.  Systemd should know when network devices like Wifi disconnect and reconnect.  It should also know if the daemon is running.   It should start the daemon on the condition that the network has been brought up and it is not already running.

 

Now ... what am I missing ???   Why would it start without networking being up?  Why would anyone restart the service every 10 seconds?  Sounds brain dead to me!   Typical SysV init would run the network up/down scripts and get this right.  Systemd SHOULD get this right, and I'm sure someone will say its been misconfigured or whatever, but notice two different mind-sets here.  One person wants it to just work with focus on easy - and who cares what damage it may cause.  The other person wants people to stop and read (no matter how unrealistic that may be).

 

I once had someone tell me they couldn't print ... they said some error message kept popping up.  I said, "What does it say?"  They said, "I dunno".  I said, "Well, try it again and read it!"  And I could tell they were mad that I wouldn't run over there and fix their stupid Windows problem ... they did not want to read me any technical jargon from some error message on the screen!   The response was, "Nevermind."     ... WHAT?  ... Guess what the Error said?  

Spoiler


https://github.com/u.../bashTheObjects -- Object Oriented Programming in BASH !!
https://eddon.systems -- Stuff I'm Working on.


#88
cusco-travel-services

cusco-travel-services

    Newbie

  • Members
  • Pip
  • 4 posts

The systemd folks site that this shouldn't be necessary since "modern" systems

 

cite is the correct word in this context, not site.

 

He says the daemon is bi-polar because it will retry if the network is up when its started, but not other times, and sites network connectivity problems may not be local.

 

As above, it should be cites instead of sites.

 

We have to think of the Members whose native language is not English so that it is easier for them to learn and understand mate.

 

From your friendly grammar and spelling nazi. ;)



#89
b9AcE

b9AcE

    Newbie

  • Members
  • Pip
  • 1 posts

It's simple really: systemd is wrong for Linux.

It may be right for something else, but not (default) Linux.

It violates the "UNIX Philosophy", which is best summarized by the famous quote from the inventor of the UNIX-pipe, McIlroy:
 

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.


This is important for very many reasons.

If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. This results in that if any of those sub-functionalities "goes nuts", even if it's one that the user does not care about at all, the entire process with all its hosted sub-functionality is immediately affected. Also made obvious by the svchost.exe example is how it makes granular permissions management impossible even with third party tools like anti-virus and firewalls as if you have even ONE svchost.exe sub-functionality requiring network access to do its job, you must grant network access to the entire process and thus to everything else hosted by the same binary and this can lead to very undesirable security implications.

I use svchost.exe as the example because we Linux- (and UNIX- in general) users used to laugh at Windows' poor design in this regard for these reasons... but now when Windows is moving more and more away from this design, Linux is moving to it.

What's even worse is that there used to be several alternatives to chose from regarding system init provider, but now there are only two main ones and one that is being migrated away from, so if any major flaw is discovered in for example systemd, there is now effectively only ONE choice left.

With software now increasingly being made specifically designed for systemd, they build bi-directional dependencies so that the user can not really choose individual components anymore, which again can cause very bad security results as well as very much waste in system resources.

Imagine for example if there is a bug that causes the boot process to take half an hour each time using systemd and OpenRC can't be used because the core functionality of the system specifically depends on systemd... This can cause very expensive fines for corporations with Service Level Agreements to honor.

The migration to systemd results in user-unfriendly, bloated, unnecessarily restricted and potentially very costly systems.

It could be AN option, but should definitely not become the ONLY option as it is becoming now.

If you want a Windows/Mac-like system where the user is put out of control through the assumption that the programmers will be able to predict every usage scenario and never write flawed code so no options are needed, then it should be considered as an option.

 

I could go on, but I fear I have already passed the wall-of-text/TL;DR-threshold.

P.S.: The example scenarios in this post are all ones that I have personally encountered, so not at all hypothetical.


  • nrc, stac80 and cusco-travel-services like this



Reply to this topic



  



Also tagged with one or more of these keywords: systemd, opinion

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users