Announcement

Collapse
No announcement yet.

Systemd In Ten Years Has Redefined The Linux Landscape

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

  • finalzone
    replied
    Originally posted by Paul Frederick View Post

    I submitted a bug report but the project deleted everything before 2018. It was totally related to SystemD too. I can do plenty. The question remains will I? The answer to that is no. Now have a Merry Christmas.
    What was the title of that bug report and the name of the project in question? Those are simple request easy to answer. You claimed the issue was related to systemd so would you mind to link the issue inside the systemd bug report to verify your claim?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Farmer View Post
    Find in my post where I stated that mariadb is on an NFS share. Give it a shot. It isn't. What I made clear was that neither mariadb nor nfs started upon boot. At no point did I state that mariadb files were on an NFS share. Mariadb is used behind a web server whereas I use NFS to share files between computers. Different purposes entirely and not intermixed.
    This kind of failure pattern of mariadb being linked to NFS shares is in fact common if you started with a cloud configured item.

    Originally posted by Farmer View Post
    systemctl enable is the recommended command to enable this. It doesn't work. That's broken out of the box. Get over it..
    This is still novice answer. You have shown nothing that the command systemctl enable does not in fact work.

    Enable one or more units or unit instances. This will create a set of symlinks, as encoded in the "[Install]" sections of the indicated unit files. After the symlinks have been created, the system manager configuration is reloaded (in a way equivalent to daemon-reload), in order to ensure the changes are taken into account immediately. Note that this does not have the effect of also starting any of the units being enabled. If this is desired, combine this command with the --now switch, or invoke start with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of the form [email protected]), symlinks named the same as instances are created in the unit configuration directory, however they point to the single template unit file they are instantiated from.
    This is from the systemctl man page. Where does it say the service will absolutely start by doing systemctl enable. Answer it does not. Enabled services will be tried on boot and if they fail the they will stay down. You need to check status with "systemctl status service" to find out why. With sysvinit you had to dig though logs.

    MSDOS when this happen pure ass no status or logs to work out what you had done wrong sometimes you would just keep on swapping stuff around until it worked with MSDOS.

    Originally posted by Farmer View Post
    If it wasn't broken out of the box httpd wouldn't start either but that one does. That they all run when manually started makes clear they all work.
    Out box on most distributions httpd will not be linked by service unit files to databases starting. The fact httpd starts tells me the enable command worked correctly. You have not modified the unit files to make httpd not start until you have database up.
    https://www.freedesktop.org/software...temd.unit.html

    Basically you will be wanting one of "wants=","requires=" or "Requisite=" and possible a "after=" value set.

    Originally posted by Farmer View Post
    Clearly I'm no novice.
    No clearly novice. You don't understand what the command means. And you are not doing diagnostics.

    Originally posted by Farmer View Post
    Except for systemd. The one thing systemd was intended to do was deal with services. It cannot even do that right. Even MS-DOS managed that.
    There is a very good old saying. Garbage in, Garbage out. Systemd is only as good as it configuration. If it configured wrong it will still service manage. Ok it may decide try to start something see error and stop that service fully. This is still proper service management like it or not. It will have recorded a status of what went wrong if you are too much of a idiot to read that its not my problem its yours.

    You are dealing with a old school dos user who did complex autoexec.bat and config.sys. I can tell you if you start things in the wrong order on MSDOS TSR programs magically did not start either. This was kind important so networking and sound worked with dos applications. So the problem you just happens under MSDOS as well.

    Really at this point you are sounded like a person who has put the old harddrive command park heads in autoexec.bat and wondering why they cannot access their computer and blaming MSDOS. Sorry referring to MSDOS tells me you were only a novice with that and you thought you were an expert when you were not.

    Originally posted by Farmer View Post
    How much effort it takes to fix it is irrelevant. It didn't work correctly on a clean bog simple installation.
    Webserver + a database is not a bog simple solution to setup right. Because database used with webserver could be postgresql, mysql, mariadb..... and the list goes on. Webserver + database means you have to manually alter the init system so it does the right things and its not possible for the distribution to set this out the box right. Yes just because you install a database does not mean the webserver will be using it either. This was in fact true back with sysvinit as well this is not a new problem. Systemd has a different of doing this compared to old sysvinit.

    Distributions are meant to provide default configurations to systemd that makes general stuff simple. Maybe you should name the distribution instead of just blaming systemd and start looking at their maintainers.

    Leave a comment:


  • Paul Frederick
    replied
    Originally posted by finalzone View Post

    Still asking you to provide the scenario with the name of the desktop environment, the name of the distribution running your system and reproduce the problem seemly related to systemd so viewers can see what is exactly going on. Additionally, a link to a bug report will help. Those are very simple requests. Can you do that?
    The correct spelling is systemd by the way.
    I submitted a bug report but the project deleted everything before 2018. It was totally related to SystemD too. I can do plenty. The question remains will I? The answer to that is no. Now have a Merry Christmas.

    Leave a comment:


  • Paul Frederick
    replied
    Originally posted by k1e0x View Post

    Window Maker? No shame there..
    Window Maker is a Window Manager not a Desktop Environment.

    Leave a comment:


  • finalzone
    replied
    Originally posted by Paul Frederick View Post

    This isn't a court of law numb nuts. I don't use that DE anymore because it didn't work. SystemD made me fall back to how I ran Linux 20 years ago. How's that for progress?
    Still asking you to provide the scenario with the name of the desktop environment, the name of the distribution running your system and reproduce the problem seemly related to systemd so viewers can see what is exactly going on. Additionally, a link to a bug report will help. Those are very simple requests. Can you do that?
    The correct spelling is systemd by the way.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by Paul Frederick View Post

    This isn't a court of law numb nuts. I don't use that DE anymore because it didn't work. SystemD made me fall back to how I ran Linux 20 years ago. How's that for progress?
    Window Maker? No shame there..

    Leave a comment:


  • Paul Frederick
    replied
    Originally posted by finalzone View Post
    Paul Frederick
    Tell the name of the Desktop Environment you use. You started the claim related to systemd so the burden of proof is on you.
    This isn't a court of law numb nuts. I don't use that DE anymore because it didn't work. SystemD made me fall back to how I ran Linux 20 years ago. How's that for progress?

    Leave a comment:


  • Farmer
    replied
    Originally posted by oiaohm View Post

    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 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.
    Find in my post where I stated that mariadb is on an NFS share. Give it a shot. It isn't. What I made clear was that neither mariadb nor nfs started upon boot. At no point did I state that mariadb files were on an NFS share. Mariadb is used behind a web server whereas I use NFS to share files between computers. Different purposes entirely and not intermixed.

    systemctl enable is the recommended command to enable this. It doesn't work. That's broken out of the box. Get over it. If it wasn't broken out of the box httpd wouldn't start either but that one does. That they all run when manually started makes clear they all work.

    On new hardware the only two issues I encountered were a driver not loading for one of the RAID cards and systemd not starting two services.

    The RAID card issue was due to lack of the PCI ID in the database. Filed a bug, with fix, that they baked a new kernel for me to test. The fixed that. Until then I manually loaded it.

    Clearly I'm no novice.

    20 years ago when loading a new machine from scratch, as I did for this one, almost everything needed fixing. It typically took a good half hour just to get the fonts reasonable.

    Today, out of the box, only one of the software packages misbehaved. Over 1,000 packages and everything worked peachy.

    Except for systemd.

    The one thing systemd was intended to do was deal with services. It cannot even do that right. Even MS-DOS managed that.

    This is typically the point where fanbois are full of excuses and information technology advice. Missing the point entirely. Just like every other package on the machine it should work as claimed by default. It didn't. That's brittle software.

    How much effort it takes to fix it is irrelevant. It didn't work correctly on a clean bog simple installation. Every other package did. Well, excepting the PCI ID for the obscure RAID card thing anyway.


    Leave a comment:


  • finalzone
    replied
    Paul Frederick
    Tell the name of the Desktop Environment you use. You started the claim related to systemd so the burden of proof is on you.

    Leave a comment:


  • pal666
    replied
    Originally posted by rmoog View Post
    Nice idea. Awful implementation. Megalomaniac developer.
    imbecilic haters

    Leave a comment:

Working...
X