Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.os.unix.linux.misc > #115611 > unrolled thread

FYI: why systemd sucks

Started byAndreas Neumann <an5275@sedo.com>
First post2021-03-14 17:14 +0200
Last post2021-03-15 04:23 +0000
Articles 20 on this page of 189 — 32 participants

Back to article view | Back to de.comp.os.unix.linux.misc


Contents

  FYI: why systemd sucks Andreas Neumann <an5275@sedo.com> - 2021-03-14 17:14 +0200
    Re: FYI: why systemd sucks Arno Lutz <invalid@freakmail.de> - 2021-03-14 20:00 +0100
      Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-14 20:16 +0100
        Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-14 21:25 +0000
          Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-14 23:39 +0100
            Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-14 23:37 +0000
              Re: FYI: why systemd sucks Hans CraueI <crauel_usenet@freenet.de> - 2021-03-14 23:58 +0000
                Re: FYI: why systemd sucks Frank Miller <miller@posteo.ee> - 2021-03-15 03:48 +0100
                  Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 08:53 +0100
                  Re: FYI: why systemd sucks Hans CraueI <crauel_usenet@freenet.de> - 2021-03-15 09:59 +0000
                    Re: FYI: why systemd sucks Matthias Gerds <m.gerds@posteo.de> - 2021-03-16 05:33 +0100
                      Re: FYI: why systemd sucks Matthias Gerds <m.gerds@posteo.de> - 2021-03-16 05:58 +0100
                        Re: FYI: why systemd sucks Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-16 20:29 +0100
                        Re: FYI: why systemd sucks Christian Schumacher <cs.spam@nurfuerspam.de> - 2021-03-24 21:31 +0100
                      Re: FYI: why systemd sucks Hans CraueI <crauel_usenet@freenet.de> - 2021-03-19 14:01 +0000
                        Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-19 14:33 +0000
          Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-15 14:34 +0100
            Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-15 13:49 +0000
            Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-15 15:32 +0100
              Re: FYI: why systemd sucks Holger Schieferdecker <spamless@gmx.de> - 2021-03-18 15:07 +0100
            Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 11:19 -0400
              Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-15 16:31 +0100
                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 17:25 +0100
                  Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-15 18:21 +0100
              Re: FYI: why systemd sucks Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-03-15 18:00 +0100
                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 18:53 +0100
                  Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 14:29 -0400
                    Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 21:41 +0100
          Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-15 21:27 +0100
            Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 21:48 +0100
              Re: FYI: why systemd sucks Joerg <news@analogconsultants.com> - 2021-03-15 14:21 -0700
                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 22:48 +0100
                  Re: FYI: why systemd sucks Joerg <news@analogconsultants.com> - 2021-03-15 15:11 -0700
              Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-16 07:52 +0100
                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 16:55 +0100
            Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-15 22:06 +0000
              Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 23:30 +0100
              Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-17 19:14 +0100
                Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-17 19:22 +0100
                Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-17 21:48 +0000
                  Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 13:49 +0100
                    Re: FYI: why systemd sucks Joerg <news@analogconsultants.com> - 2021-03-18 12:02 -0700
                      Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-18 20:32 +0100
                        Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 21:26 +0100
                          Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-19 01:18 +0100
                    Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-18 23:55 +0100
                      Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-19 01:10 +0100
                        Re: FYI: why systemd sucks Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 20:39 +0100
                      Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-18 22:02 -0400
                        Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-19 20:46 +0100
                          Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-19 16:54 -0400
                  Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-18 23:43 +0100
                    Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-19 10:58 +0000
                      Re: FYI: why systemd sucks Ralph Angenendt <dein.name@strg-alt-entf.org> - 2021-03-19 11:35 +0000
                        Re: FYI: why systemd sucks Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-19 12:14 +0000
                        Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-19 11:58 -0400
                          Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-19 19:26 +0100
                            Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-19 15:38 -0400
        Re: FYI: why systemd sucks Juergen Ilse <news@usenet-verwaltung.de> - 2021-03-15 04:27 +0000
          Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-15 10:46 +0100
            Re: FYI: why systemd sucks Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-15 20:28 +0100
              Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-16 09:20 +0100
          Re: FYI: why systemd sucks Thomas Dorner <de.comp.os.unix.linux.misc.210315.dorner@spamgourmet.com> - 2021-03-15 19:08 +0100
            Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-15 19:23 +0100
              Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-15 21:43 +0000
                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 23:33 +0100
                  Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-16 18:10 +0100
              Re: FYI: why systemd sucks Thomas Dorner <de.comp.os.unix.linux.misc.210316.dorner@spamgourmet.com> - 2021-03-16 15:59 +0100
                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 16:57 +0100
                  Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-16 18:10 +0100
                    Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 19:43 +0100
                      Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-16 20:22 +0100
            Re: FYI: why systemd sucks Paul Muster <exp-311221@news.muster.net> - 2021-03-15 19:29 +0100
              Re: FYI: why systemd sucks Juergen Ilse <news@usenet-verwaltung.de> - 2021-03-15 20:27 +0000
                Re: FYI: why systemd sucks Thomas Dorner <de.comp.os.unix.linux.misc.210316.dorner@spamgourmet.com> - 2021-03-16 16:04 +0100
                  Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 17:12 +0100
          Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-15 21:34 +0100
            Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-15 21:40 +0000
            Re: FYI: why systemd sucks Juergen Ilse <news@usenet-verwaltung.de> - 2021-03-15 22:02 +0000
              Re: FYI: why systemd sucks Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-03-15 22:54 +0000
              Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-15 23:55 +0100
                Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 20:53 -0400
                  Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 17:19 +0100
                    Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-16 14:17 -0400
                      Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 19:34 +0100
                        Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-16 17:47 -0400
                          Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-16 23:31 +0100
                Re: FYI: why systemd sucks Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-03-16 08:06 +0000
              Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-17 19:25 +0100
                Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-17 19:56 +0100
                Re: FYI: why systemd sucks Stephan Seitz <stse+usenet@rootsland.net> - 2021-03-17 21:43 +0000
                  Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 13:57 +0100
                    Re: FYI: why systemd sucks Stephan Seitz <stse+usenet@rootsland.net> - 2021-03-18 17:28 +0000
                      Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 21:29 +0100
                  Re: FYI: why systemd sucks Thomas Dorner <de.comp.os.unix.linux.misc.210318.dorner@spamgourmet.com> - 2021-03-18 16:16 +0100
                    Re: FYI: why systemd sucks Stephan Seitz <stse+usenet@rootsland.net> - 2021-03-18 17:31 +0000
                      Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 21:32 +0100
                        Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-19 00:38 +0100
                        Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-19 01:06 +0100
                          Re: FYI: why systemd sucks Klaus von der Heyde <asc.soc@freenet.de> - 2021-03-19 18:17 +0000
                Re: FYI: why systemd sucks Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-03-17 21:47 +0000
                  Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 13:58 +0100
                    Re: FYI: why systemd sucks Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-03-18 13:41 +0000
                    Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-18 18:53 +0100
                      Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-18 19:03 +0100
                        Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-18 21:33 +0100
                          Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-18 21:49 +0100
                      Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-19 00:05 +0100
                        Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-19 12:20 +0100
                          Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-19 20:16 +0100
                            Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-19 21:06 +0100
                              Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-20 09:04 +0100
                                Re: FYI: why systemd sucks Stephan Seitz <stse+usenet@rootsland.net> - 2021-03-20 14:35 +0000
                                Re: FYI: why systemd sucks Hans CraueI <crauel_usenet@freenet.de> - 2021-03-20 15:52 +0000
                                  Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-20 13:11 -0400
                                    Re: FYI: why systemd sucks Hans CraueI <crauel_usenet@freenet.de> - 2021-03-21 12:56 +0000
                                      Re: FYI: why systemd sucks Ralph Angenendt <dein.name@strg-alt-entf.org> - 2021-03-22 11:40 +0000
                                        Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-22 14:51 +0100
                                          Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-22 18:10 +0100
                                            Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-22 19:53 +0100
                                              Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-23 10:03 +0100
                                                Re: FYI: why systemd sucks Klaus von der Heyde <asc.soc@freenet.de> - 2021-03-23 18:02 +0000
                                                  Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-23 19:15 +0000
                                                  Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-24 08:57 +0100
                                                  Re: FYI: why systemd sucks Stefan Reuther <stefan.news@arcor.de> - 2021-03-24 17:58 +0100
                                                    Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-24 18:59 +0100
                                                      Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-24 18:46 -0400
                                                        Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 07:57 +0100
                                                          Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-25 11:04 -0400
                                                            Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 18:10 +0100
                                                              Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-25 13:45 -0400
                                                                Re: FYI: why systemd sucks Klaus von der Heyde <asc.soc@freenet.de> - 2021-03-25 18:11 +0000
                                                                Re: FYI: why systemd sucks Paul Muster <exp-311221@news.muster.net> - 2021-03-25 19:18 +0100
                                                                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-25 19:22 +0100
                                                              Re: FYI: why systemd sucks Paul Muster <exp-311221@news.muster.net> - 2021-03-25 19:25 +0100
                                                                Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-26 08:25 +0100
                                                        Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-25 07:29 +0000
                                                          Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 08:52 +0100
                                                            Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-25 08:31 +0000
                                                              Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 13:40 +0100
                                                                Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-26 06:08 +0100
                                                                  Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-26 08:29 +0100
                                                                    Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-26 12:43 +0100
                                                                    Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-27 11:10 +0100
                                                              Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-26 05:51 +0100
                                                                Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-26 08:34 +0100
                                                                  Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-26 12:58 +0100
                                                            Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-25 19:14 +0100
                                                              Re: FYI: why systemd sucks Andreas Kohlbach <ank@spamfence.net> - 2021-03-25 21:22 -0400
                                                              Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-26 12:15 +0100
                                                      Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-25 07:28 +0000
                                                        Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 08:55 +0100
                                                          Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-25 08:27 +0000
                                                    Re: FYI: why systemd sucks Klaus von der Heyde <asc.soc@freenet.de> - 2021-03-24 18:54 +0000
                                                      Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 08:16 +0100
                                                    Re: FYI: why systemd sucks Bastian Blank <usenet@waldi.eu.org> - 2021-03-25 07:25 +0000
                                                      Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 08:56 +0100
                                                        Re: FYI: why systemd sucks Paul Muster <exp-311221@news.muster.net> - 2021-03-25 09:09 +0100
                                                          Re: FYI: why systemd sucks Thomas Noll <-_tn_-@web.de> - 2021-03-25 09:45 +0000
                                                          Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 13:41 +0100
                                                    Re: FYI: why systemd sucks Marcus Jodorf <trap@killfile.de> - 2021-03-26 05:17 +0100
                                            Re: FYI: why systemd sucks Stephan Seitz <stse+usenet@rootsland.net> - 2021-03-22 20:40 +0000
                                              Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-23 10:04 +0100
                                  Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-21 19:03 +0100
                                    Re: FYI: why systemd sucks Paul Muster <exp-311221@news.muster.net> - 2021-03-21 19:30 +0100
                                      Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-22 18:11 +0100
                                        Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-22 20:00 +0100
                                          Re: FYI: why systemd sucks Thomas Hochstein <thh@thh.name> - 2021-03-22 23:21 +0100
                                          Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-23 10:10 +0100
                                      Re: FYI: why systemd sucks Arno Welzel <usenet@arnowelzel.de> - 2021-03-22 18:13 +0100
                                        Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-22 20:11 +0100
                                          Re: FYI: why systemd sucks Stefan Reuther <stefan.news@arcor.de> - 2021-03-23 17:57 +0100
                                            Re: FYI: why systemd sucks "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-03-23 17:30 +0000
                                              GNU dd POSIX-konform oder nicht? (was: FYI: why systemd sucks) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-03-24 11:15 +0100
                                                Re: GNU dd POSIX-konform oder nicht? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-03-25 19:32 +0000
                                                  Re: GNU dd POSIX-konform oder nicht? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-03-26 11:13 +0100
                                Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-20 19:04 +0100
                            Re: FYI: why systemd sucks Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-20 09:06 +0100
                              Re: FYI: why systemd sucks "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-03-20 15:33 +0000
                          Re: FYI: why systemd sucks "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-03-19 20:04 +0000
                            Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-19 21:39 +0100
                              Re: FYI: why systemd sucks "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-03-20 15:35 +0000
                              Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-20 16:35 +0100
    Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-14 21:04 +0100
      Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-14 21:29 +0100
        Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-14 21:50 +0100
          Re: FYI: why systemd sucks Kay Martinen <usenet@martinen.de> - 2021-03-14 23:19 +0100
            Re: FYI: why systemd sucks Tim Ritberg <tim@server.invalid> - 2021-03-15 10:47 +0100
    Re: FYI: why systemd sucks Juergen Ilse <news@usenet-verwaltung.de> - 2021-03-15 04:23 +0000

Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10  Next page →


#115984

FromMarcus Jodorf <trap@killfile.de>
Date2021-03-26 06:08 +0100
Message-ID<877dlujyc9.fsf-bofh@killfile.de>
In reply to#115961
Marc Haber <mh+usenetspam1118@zugschl.us> schrieb:


> Bei dieser Maschine musste ich gewaltig eingreifen, weil der named
> auch auf einer der OpenVPN-Tunnel-IPs lauschen soll und somit gewartet
> werden muss, bis das Netzwerk komplett da ist (und keine IPv6-Adressen
> mehr tentative sind), bevor der OpenVPN-Daemon gestartet wird, dann
> gewartet werden muss, bis das Tunnel-Interface da und komplett
> konfiguriert ist (und keine IPv6-Adressen mehr tentative sind) bevor
> der named gestartet werden darf.

Das sieht schon extrem lahm aus.

graphical.target @13.786s
└─multi-user.target @13.786s
  └─vmware-workstation-server.service @11.503s +2.282s
    └─vmware.service @9.245s +2.255s
      └─network-online.target @9.239s
        └─NetworkManager-wait-online.service @1.846s +7.391s
          └─NetworkManager.service @1.579s +256ms
            └─dbus.service @1.575s
              └─basic.target @1.563s
                └─sockets.target @1.563s
                  └─pcscd.socket @1.563s
                    └─sysinit.target @1.553s
                      └─systemd-timesyncd.service @1.478s +75ms
                        └─systemd-tmpfiles-setup.service @1.440s +34ms
                          └─local-fs.target @1.436s
                            └─run-vmblock\x2dfuse.mount @10.182s
                              └─local-fs-pre.target @429ms
                                └─systemd-tmpfiles-setup-dev.service @410ms +19>
                                  └─systemd-sysusers.service @366ms +42ms
                                    └─systemd-remount-fs.service @336ms +27ms
                                      └─systemd-journald.socket @316ms
                                        └─system.slice @232ms
                                          └─-.slice @232ms

Das ist mein oller Lapop zum Vergleich. Das ist ein alter, gemütlicher Skylake mit
i5-6300U, der da auch noch jedem Menge Zeugs startet. Samt vmware and
Strongswan IPsec im Hintergrund. Und nur per noch gammeligerem 802.11g
angebunden (echter WRT54g noch im Betrieb;-).
Wie immer ist aber die Ausgabe von systemd zwischen Anfang und Ende mehr dem
butterfly effect geschuldet und sieht meistens jedesmal komplett anders
aus.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]


#115986

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-26 08:29 +0100
Message-ID<s3k2gm$bdv$1@news1.tnib.de>
In reply to#115984
Marcus Jodorf <trap@killfile.de> wrote:
>graphical.target @13.786s
>??multi-user.target @13.786s
>  ??vmware-workstation-server.service @11.503s +2.282s
>    ??vmware.service @9.245s +2.255s
>      ??network-online.target @9.239s
>        ??NetworkManager-wait-online.service @1.846s +7.391s
>          ??NetworkManager.service @1.579s +256ms
>            ??dbus.service @1.575s
>              ??basic.target @1.563s
>                ??sockets.target @1.563s
>                  ??pcscd.socket @1.563s
>                    ??sysinit.target @1.553s
>                      ??systemd-timesyncd.service @1.478s +75ms
>                        ??systemd-tmpfiles-setup.service @1.440s +34ms
>                          ??local-fs.target @1.436s
>                            ??run-vmblock\x2dfuse.mount @10.182s
>                              ??local-fs-pre.target @429ms
>                                ??systemd-tmpfiles-setup-dev.service @410ms +19>
>                                  ??systemd-sysusers.service @366ms +42ms
>                                    ??systemd-remount-fs.service @336ms +27ms
>                                      ??systemd-journald.socket @316ms
>                                        ??system.slice @232ms
>                                          ??-.slice @232ms
>
>Das ist mein oller Lapop zum Vergleich. Das ist ein alter, gemütlicher Skylake mit
>i5-6300U, der da auch noch jedem Menge Zeugs startet. Samt vmware and
>Strongswan IPsec im Hintergrund. Und nur per noch gammeligerem 802.11g
>angebunden (echter WRT54g noch im Betrieb;-).
>Wie immer ist aber die Ausgabe von systemd zwischen Anfang und Ende mehr dem
>butterfly effect geschuldet und sieht meistens jedesmal komplett anders
>aus.

Hier noch ein anderer Server:
|graphical.target @1min 4.126s
|+-multi-user.target @1min 4.126s
|  +-zg2-rebootscript.service @3.810s +6.690s
|    +-basic.target @3.791s
|      +-sockets.target @3.791s
|        +-virtlogd.socket @3.791s
|          +-sysinit.target @3.776s
|            +-systemd-update-utmp.service @3.646s +129ms
|              +-systemd-tmpfiles-setup.service @3.550s +95ms
|                +-systemd-journal-flush.service @3.279s +270ms
|                  +-var.mount @2.625s +651ms
|                    +-dev-mapper-gancho\x2dvar.device @2.625s

(zg2-rebootscript nimmt die letzten 1000 Zeilen des syslogs und
vermailt sie, vielleicht muss das irgendwie noch auf Netz und DNS
warten?)

Und hier noch einer:
|graphical.target @1min 13.051s
|+-multi-user.target @1min 13.050s
|  +-exim4.service @12.789s +31.801s
|    +-basic.target @12.364s
|      +-sockets.target @12.348s
|        +-avahi-daemon.socket @12.333s
|          +-network-online.target @12.317s
|            +-systemd-networkd-wait-online.service @6.870s +5.429s
|              +-systemd-networkd.service @6.541s +309ms
|                +-network-pre.target @6.521s
|                  +-ferm.service @3.945s +2.559s
|                    +-var.mount @3.717s +138ms
|                      +-dev-mapper-prom\x2dprom_var.device @3.697s

Meine Arbeitsplatzrechner taugen nicht als Maßstab, die haben alle
verschlüsselte Platten und die Wartezeit auf die Passworteingabe zählt
voll mit.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115994

FromMarcus Jodorf <trap@killfile.de>
Date2021-03-26 12:43 +0100
Message-ID<87pmzmnnrz.fsf-bofh@killfile.de>
In reply to#115986
Marc Haber <mh+usenetspam1118@zugschl.us> schrieb:

> Meine Arbeitsplatzrechner taugen nicht als Maßstab, die haben alle
> verschlüsselte Platten und die Wartezeit auf die Passworteingabe zählt
> voll mit.

?
Mein Laptop Beispiel ist mit verschlüsselter Platte und ich seh da keine
Wartezeit in der Ausgabe. Die Passworteingabe schaffe ich nicht in
Millisekunden.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]


#116003

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-27 11:10 +0100
Message-ID<s3n0b3$kkf$1@news1.tnib.de>
In reply to#115986
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>Meine Arbeitsplatzrechner taugen nicht als Maßstab, die haben alle
>verschlüsselte Platten und die Wartezeit auf die Passworteingabe zählt
>voll mit.

Trotzdem hab ich das gestern mal gestoppt. Kernel Laden Ende bei Null,
Loginprompt bei 20, KDE-Desktop nutzbar bei 32 Sekunden.

|graphical.target @1min 7.448s
|+-multi-user.target @1min 7.448s
|  +-smartmontools.service @7.430s +898ms
|    +-basic.target @7.390s
|      +-sockets.target @7.390s
|        +-avahi-daemon.socket @7.390s
|          +-network-online.target @7.390s
|            +-systemd-networkd-wait-online.service @1.008s +6.381s
|              +-systemd-networkd.service @926ms +79ms
|                +-network-pre.target @922ms
|                  +-ferm.service @207ms +712ms
|                    +-systemd-journald.socket @202ms
|                      +--.mount @196ms
|                        +-blockdev@dev-mapper-root.target @530ms
|                          +-systemd-cryptsetup@root.service @496ms +10ms
|                            +-dev-disk-by\x2did-dm\x2dname\x2dfan\x2dc_root.d

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115983

FromMarcus Jodorf <trap@killfile.de>
Date2021-03-26 05:51 +0100
Message-ID<87blb6jz52.fsf-bofh@killfile.de>
In reply to#115958
Bastian Blank <usenet@waldi.eu.org> schrieb:

> Weil Debian nie was anderes hatte. Und graphical.target halt als
> default.target bekannt ist.

Letzlich finde ich das critical-chain Zeugs schon irgendwie wertlos.
Mehr so eine Hipsterspieleri (Metriken! Wir brauche Metriken! Egal was
die bedeuten, haupsache sieh gut auf einer Powerpointfolie aus!)


Weil: Das hier sind zwei völlig identische (Hardware und Software)
Linuxkisten.

Der erste sagt:

graphical.target @17.477s
└─multi-user.target @17.477s
  └─sysfsutils.service @17.458s +18ms
    └─cpufrequtils.service @17.161s +294ms
      └─loadcpufreq.service @16.997s +163ms
        └─remote-fs.target @16.981s
          └─usr-local-share-export.mount @12.462s +4.515s
            └─network-online.target @12.455s
              └─ifupdown-wait-online.service @238ms +12.032s
                └─systemd-journald.socket @216ms
                  └─system.slice @122ms
                    └─-.slice @122ms


Der Zweite:

graphical.target @17.796s
└─multi-user.target @17.796s
  └─postgresql.service @17.794s +1ms
    └─postgresql@11-main.service @15.518s +2.274s
      └─network.target @15.516s
        └─networking.service @10.123s +5.390s
          └─ifupdown-pre.service @330ms +9.789s
            └─systemd-udev-trigger.service @186ms +143ms
              └─systemd-udevd-kernel.socket @185ms
                └─system.slice @169ms
                  └─-.slice @169ms

Aha! Beide letzlich weitgehend gleich schnell (was'n Wunder!).
Der Rest ist mehr so sinnloses Rauschen, für das jemand
vielleicht einfach gewürfelt hat.
Sieht nach jedem Re-boot auch komplett neu ausgewürfelt aus, was es IMHO
einfach reichlich sinnlos macht.
Evtl. sieht man bei tausend Neustarts ja sogar ein Muster, aber so nützt
es mir einfach so ziemlich genau nichts.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]


#115987

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-26 08:34 +0100
Message-ID<s3k2q5$brm$1@news1.tnib.de>
In reply to#115983
Marcus Jodorf <trap@killfile.de> wrote:
>Letzlich finde ich das critical-chain Zeugs schon irgendwie wertlos.
>Mehr so eine Hipsterspieleri (Metriken! Wir brauche Metriken! Egal was
>die bedeuten, haupsache sieh gut auf einer Powerpointfolie aus!)

Ich denke es ist schon hilfreich in den Fällen, wo es heißt, dass
irgend ein System zu lange braucht um zu booten. Auf meinen Kisten
gibt es immer irgend einen Prozess der die Bootzeit auf > 1 Minute
hebt, und ich habe aus den für diesen Thread gesammelten Ergebnissen
schon wieder auf "es ist immer DNS" geschlossen. Vielleicht hab ich
irgendwann ja mal Lust, der Sache genauer auf den Grund zu gehen,
dummerweise debuggt es sich auf den Virtualisierung-Blechen so
schlecht wenn immer gleich ein Stapel Dienste mit weg ist.

Das hier wäre eine Kiste, die ich schmerzlos durchtreten könnte...
|graphical.target @1min 12.448s
|+-multi-user.target @1min 12.448s
|  +-exim4.service @12.393s +2.002s
|    +-basic.target @11.970s
|      +-sockets.target @11.954s
|        +-virtlockd-admin.socket @4.586s
|          +-sysinit.target @4.326s
|            +-systemd-update-utmp.service @4.174s +73ms
|              +-systemd-tmpfiles-setup.service @4.058s +63ms
|                +-systemd-journal-flush.service @3.910s +68ms
|                  +-var.mount @3.702s +123ms
|                    +-systemd-fsck@dev-mapper-aida\x2daida_var.service @3.518s
|                      +-dev-mapper-aida\x2daida_var.device @3.104s

aber dummerweise ist die Ausgabe beim Booten ja auch nicht mehr
wirklich hilfreich, seit es den Login-Prompt "irgendwann" gibt und
systemctl is-system-running nach dem Login immernoch lapidar
"starting" sagt. Da muss mna dem System schon mit tcpdump auf die
Finger gucken.

Hier noch ein Banana Pi:
|graphical.target @1min 13.673s
|+-multi-user.target @1min 13.668s
|  +-exim4.service @13.104s +3.639s
|    +-basic.target @12.840s
|      +-sockets.target @12.824s
|        +-avahi-daemon.socket @12.805s
|          +-network-online.target @12.785s
|            +-systemd-networkd-wait-online.service @4.185s +8.583s
|              +-systemd-networkd.service @3.850s +300ms
|                +-systemd-udevd.service @3.634s +161ms
|                  +-systemd-tmpfiles-setup-dev.service @3.454s +118ms
|                    +-systemd-sysusers.service @3.251s +177ms
|                      +-systemd-remount-fs.service @2.589s +450ms
|                        +-systemd-journald.socket @1.961s
|                          +--.mount @769ms
|                            +--.slice @769ms


Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115995

FromMarcus Jodorf <trap@killfile.de>
Date2021-03-26 12:58 +0100
Message-ID<87lfaann2x.fsf-bofh@killfile.de>
In reply to#115987
Marc Haber <mh+usenetspam1118@zugschl.us> schrieb:

> Hier noch ein Banana Pi:

Ah, ok. Ich hab mich schon gewundert, warum es allgemein so
verhältnismäßig langsam ist.

Weil das hier ist zwar im Wesentlichen nur NFS Server aber ganz altes
Blech und startet auch von rotierendem Rost:

graphical.target @7.195s
└─multi-user.target @7.194s
  └─postfix.service @7.188s +3ms
    └─postfix@-.service @5.218s +1.966s
      └─network-online.target @5.215s
        └─network.target @5.097s
          └─networking.service @3.931s +1.068s
            └─local-fs.target @3.929s
              └─boot-efi.mount @3.618s +309ms
                └─dev-sdf1.device @3.549s


Und bei VMs lande ich normalerweise eher so in dem Bereich hier:

graphical.target @5.051s
└─multi-user.target @5.050s
  └─postgresql.service @5.049s +1ms
    └─basic.target @1.673s
      └─sockets.target @1.673s
        └─acpid.socket @1.673s
          └─sysinit.target @1.652s
            └─swap.target @1.652s
              └─dev-disk-by\x2duuid-1e72d9f2\x2db3d3\x2d421c\x2d8425\x2da200198933ae.swap @1.609s +43ms
                └─dev-disk-by\x2duuid-1e72d9f2\x2db3d3\x2d421c\x2d8425\x2da200198933ae.device @1.608s

Bzw. sieht das meist eher so aus, wenn da nicht so ganz viel
verschiedenes Zeugs gestartet wird:

graphical.target @2.798s
└─multi-user.target @2.798s
  └─getty.target @2.492s
    └─getty@tty1.service @2.491s
      └─systemd-user-sessions.service @2.483s +7ms
        └─network.target @2.482s
          └─networking.service @2.377s +103ms
            └─apparmor.service @2.184s +191ms

(da laufen nur postfix, postgres und ein wenig Kleinkram drauf)

Wobei das vor systemd auch nicht merklich langsamer ging.

Nebenbei alles Beispiele von Rechnern ohne SSDs.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]


#115975

FromKay Martinen <usenet@martinen.de>
Date2021-03-25 19:14 +0100
Message-ID<ng0vih-b1h.ln1@news.martinen.de>
In reply to#115953
Am 25.03.21 um 08:52 schrieb Marc Haber:
> Bastian Blank <usenet@waldi.eu.org> wrote:
>> Andreas Kohlbach wrote:
>>> Meine Vermutung war, dass er zwar im kostenlosen WIFI eine IP zugewiesen
>>> bekam, es dann aber ein Captive Portal zu bestätigen gab, was ohne fertig
>>> zu booten nicht geht (Katze <-> Schwanz). Er hatte aber keinen Zugriff
>>> auf das Internet. Zuhause gibt es kein Captive Portal, dass mir das
>>> Problem vorher nie auffiel.

Mir ist letztes Jahr aufgefallen das ein Windows 7 direkt den Browser
mit der Portalseite startet zum Login dort. Mein Ubuntu Linux aber
nicht. Dort mußte ich die richtige IP selbst suchen, aufrufen, reloaden
und erst dann hatte ich "richtig" Internet.

Dann wäre es evtl. eine sache von dhcpclient und den optionen die er
auswertet und weiter gibt an ...?

Was dann wohl dies hier wäre.

<https://tools.ietf.org/html/rfc7710>

>> Du hast "systemd-analyze critical-chain" nicht gefunden?
> 
> Das kannte ich bis eben auch nicht.

Ich kannt es auch nicht, was niemanden wundern dürfte.

> 
> |graphical.target @1min 8.649s
> |+-multi-user.target @1min 8.630s
> |  +-exim4.service @1min 8.343s +265ms
> |    +-spamassassin.service @1min 4.351s +3.965s
> |      +-network-online.target @1min 4.238s
> |        +-systemd-networkd-wait-online.service @3.966s +15.062s
> |          +-systemd-networkd.service @3.795s +59ms
> |            +-network-pre.target @3.773s
> |              +-ferm.service @2.730s +915ms
> |                +-var.mount @2.502s +132ms
> |                  +-systemd-fsck@dev-mapper-torres\x2dvar.service @2.270s +127
> |                    +-dev-mapper-torres\x2dvar.device @2.148s
> 
> Das muss man von unten nach oben lesen, richtig? Woher kommt der
> Sprung von 3 + 15 Sekunden auf 1 Minute beim network-online Target?

Zum Vergleichen. Auf meinem Ubuntu (Laptop) mit KDE siehts so aus:

> graphical.target @1min 2.883s
> └─multi-user.target @1min 2.883s
>   └─smbd.service @1min 1.247s +1.634s
>     └─winbind.service @59.539s +1.704s
>       └─nmbd.service @51.656s +7.879s
>         └─network-online.target @51.451s
>           └─NetworkManager-wait-online.service @39.934s +11.516s
>             └─NetworkManager.service @31.485s +8.445s
>               └─dbus.service @27.195s
>                 └─basic.target @26.501s
>                   └─sockets.target @26.501s
>                     └─uuidd.socket @26.501s
>                       └─sysinit.target @26.414s
>                         └─systemd-timesyncd.service @25.665s +748ms
>                           └─systemd-tmpfiles-setup.service @25.283s +305ms
>                             └─systemd-journal-flush.service @4.867s +20.414s
>                               └─systemd-journald.service @4.288s +577ms
>                                 └─systemd-journald-audit.socket @4.287s
>                                   └─system.slice @4.205s
>                                     └─-.slice @4.192s

Sind bei dir auch etliche davon Rot gefärbt? Bei mir sind es
smbd./winbind./nmbd.service und die beiden NetworkManager sowie
systemd-timesyncd.service bis systemd-journald.service

Die man page sagt nichts zur Einfärbung. Ich rief das als root auf und
der host hat

 19:02:27 up 3 days,  1:38,  3 users,  load average: 0,15, 0,22, 0,18

uptime. Als user gestartet sind auch die gleichen/obigen 9 Zeilen rot.
Ob das jobs sind die root-rechte haben/brauchen?


Kay

-- 
Posted via leafnode

[toc] | [prev] | [next] | [standalone]


#115980

FromAndreas Kohlbach <ank@spamfence.net>
Date2021-03-25 21:22 -0400
Message-ID<875z1e7lpm.fsf@usenet.ankman.de>
In reply to#115975
On Thu, 25 Mar 2021 19:14:14 +0100, Kay Martinen wrote:
>
> Am 25.03.21 um 08:52 schrieb Marc Haber:
>>>> Meine Vermutung war, dass er zwar im kostenlosen WIFI eine IP zugewiesen
>>>> bekam, es dann aber ein Captive Portal zu bestätigen gab, was ohne fertig
>>>> zu booten nicht geht (Katze <-> Schwanz). Er hatte aber keinen Zugriff
>>>> auf das Internet. Zuhause gibt es kein Captive Portal, dass mir das
>>>> Problem vorher nie auffiel.
>
> Mir ist letztes Jahr aufgefallen das ein Windows 7 direkt den Browser
> mit der Portalseite startet zum Login dort. Mein Ubuntu Linux aber
> nicht. Dort mußte ich die richtige IP selbst suchen, aufrufen, reloaden
> und erst dann hatte ich "richtig" Internet.

Hier gibt es mehrere Portale, die mögen Linux auch nicht. Keine Ahnung,
wie das mit Windows oder Android aussieht. Firefox scheint da aber eine
Portal Erkennung eingebaut haben. Chromium, GNOME Web oder Falkon aber
nicht.

Erschwerend, dass diese Portals zum Umleiten keine HTTPS Seiten
akzeptieren. Wenn ich als https//google.de nehme, kommt nur der Hinweis
(von meinem Browser), dass die Seite nicht geladen werden kann. Mit HTTP
geht kommt man dann zum Portal. Meine eigene Webseite hat kein HTTPS, als
nehme ich einfach die. :-D Trotzdem ärgerlich.

> Dann wäre es evtl. eine sache von dhcpclient und den optionen die er
> auswertet und weiter gibt an ...?
>
> Was dann wohl dies hier wäre.
>
> <https://tools.ietf.org/html/rfc7710>

Hier habe ich eine IP bekommen. Auch die Route steht.

Vor Jahren konnte ich das noch mit einem Skript machen. Deren Passwort
war im Klartext auf der Seite (in type="hidden"). Neben dem und der ID
setzte sich die URL auch noch aus meiner MAC Adresse zusammen. Da ich die
bei jedem Login anders habe, habe ich die per Skript ausgelesen, und die
mit allem anderen per "wget --spider ..." weg geschickt.

Neuerdings ist da irgendwas (was früher mal Flash war ;-) mit einem
verschlüsselten Teil. Also muss ich wieder klicken.
-- 
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[toc] | [prev] | [next] | [standalone]


#115991

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-26 12:15 +0100
Message-ID<s3kfp9$7uu$1@news1.tnib.de>
In reply to#115975
Kay Martinen <usenet@martinen.de> wrote:
>Am 25.03.21 um 08:52 schrieb Marc Haber:
>> Bastian Blank <usenet@waldi.eu.org> wrote:
>>> Andreas Kohlbach wrote:
>>>> Meine Vermutung war, dass er zwar im kostenlosen WIFI eine IP zugewiesen
>>>> bekam, es dann aber ein Captive Portal zu bestätigen gab, was ohne fertig
>>>> zu booten nicht geht (Katze <-> Schwanz). Er hatte aber keinen Zugriff
>>>> auf das Internet. Zuhause gibt es kein Captive Portal, dass mir das
>>>> Problem vorher nie auffiel.
>
>Mir ist letztes Jahr aufgefallen das ein Windows 7 direkt den Browser
>mit der Portalseite startet zum Login dort.

Könnte sein, dass Windows einen ähnlichen Mechanismus verwendet wie
manche Smartphones, die versuchen nach dem verbindungsaufbau zu einem
WLAN eine bestimmte URL anzusurfen und wenn das nicht funktioniert
eine Loginseite anzeigen.

>Mein Ubuntu Linux aber
>nicht. Dort mußte ich die richtige IP selbst suchen, aufrufen, reloaden
>und erst dann hatte ich "richtig" Internet.

Vorschaltseiten sind eine Frechheit und eine
Konnektivitätsverhinderung. Leider sind sie sowohl von den Betreibern
der WLANs ("MARKETING!!!!elf!") als auch vom Gesetzgeber ("Du musst
Den Benutzer darüber informieren, dass er nichts verbotenes tun darf,
sonst bist Du mit dran") gewollt.

>Sind bei dir auch etliche davon Rot gefärbt?

Ja.

>Ob das jobs sind die root-rechte haben/brauchen?

Oder welche die besonders lange brauchen?

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115951

FromBastian Blank <usenet@waldi.eu.org>
Date2021-03-25 07:28 +0000
Message-ID<slrns5oes6.n9q.usenet@mobilewave.waldi.eu.org>
In reply to#115936
Marc Haber wrote:
> "Braucht Netz" ist auch in systemd eine Krankheit. Das Problem ist,
> dass systemd davon ausgeht, dass sobald das "ip addr" Kommando
> abgesetzt ist, die Adresse direkt nutzbar ist, und dann die
> Applikationen auf die Nase fallen, die eine IP-Adresse binden wollen,
> die noch tentative ist.

Ich zitiere aus systemd.socket:

| If an IP address is used here, it is often desirable to listen on it
| before the interface it is configured on is up and running, and even
| regardless of whether it will be up and running at any point. To deal
| with this, it is recommended to set the FreeBind= option described
| below.

Wenn du unbedingt an einzelnen IP binden möchtest (dafür gibt es oft
bessere Lösungen), dann nimm halt IP_FREEBIND bzw IPV6_FREEBIND.

Das Problem ist ja größer und tritt auch bei so Scheiß wie IP-Failover
auf.

Bastian

[toc] | [prev] | [next] | [standalone]


#115954

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-25 08:55 +0100
Message-ID<s3hflm$a2g$1@news1.tnib.de>
In reply to#115951
Bastian Blank <usenet@waldi.eu.org> wrote:
>Marc Haber wrote:
>> "Braucht Netz" ist auch in systemd eine Krankheit. Das Problem ist,
>> dass systemd davon ausgeht, dass sobald das "ip addr" Kommando
>> abgesetzt ist, die Adresse direkt nutzbar ist, und dann die
>> Applikationen auf die Nase fallen, die eine IP-Adresse binden wollen,
>> die noch tentative ist.
>
>Ich zitiere aus systemd.socket:
>
>| If an IP address is used here, it is often desirable to listen on it
>| before the interface it is configured on is up and running, and even
>| regardless of whether it will be up and running at any point. To deal
>| with this, it is recommended to set the FreeBind= option described
>| below.

Ja, der arrogante systemd möchte halt, dass sich die ganze Welt an
seine Wünsche anpasst. Ich kann voll und ganz verstehen, dass man sich
mit so einer Attittüde eine lebendige Community an Haters einfängt.

>Wenn du unbedingt an einzelnen IP binden möchtest (dafür gibt es oft
>bessere Lösungen), dann nimm halt IP_FREEBIND bzw IPV6_FREEBIND.

Gibt es das auch auf nicht-Linux-Betriebssystemen oder muss ich dann
wieder von meinen Upstreams verlangen eine Linux-nicht-Linux-Weiche
einzubauen und zu testen?

Wie bringe ich das dem named(8)bei?

>Das Problem ist ja größer und tritt auch bei so Scheiß wie IP-Failover
>auf.

Die mir bekannten allgemein anerkannten Regeln der Technik sind mit
einem Neustart des Dienstes in so einer Situation verbunden.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115957

FromBastian Blank <usenet@waldi.eu.org>
Date2021-03-25 08:27 +0000
Message-ID<slrns5oibm.n9q.usenet@mobilewave.waldi.eu.org>
In reply to#115954
Marc Haber wrote:
>>Wenn du unbedingt an einzelnen IP binden möchtest (dafür gibt es oft
>>bessere Lösungen), dann nimm halt IP_FREEBIND bzw IPV6_FREEBIND.
> Gibt es das auch auf nicht-Linux-Betriebssystemen oder muss ich dann
> wieder von meinen Upstreams verlangen eine Linux-nicht-Linux-Weiche
> einzubauen und zu testen?

Es gibt äquivalente Mechanismen, ja. FreeBSD mindestens hat IP_BINDANY.

> Wie bringe ich das dem named(8)bei?

named(8) macht da irgendwas schon, die Kommentare sprechen aber nur von
IPv6. named(8) ist allerdings sowieso komisch.

>>Das Problem ist ja größer und tritt auch bei so Scheiß wie IP-Failover
>>auf.
> Die mir bekannten allgemein anerkannten Regeln der Technik sind mit
> einem Neustart des Dienstes in so einer Situation verbunden.

Also unsere anerkannten Regeln benötigen das nicht. Für keinen der
Services.

Bastian

[toc] | [prev] | [next] | [standalone]


#115939

FromKlaus von der Heyde <asc.soc@freenet.de>
Date2021-03-24 18:54 +0000
Message-ID<s3g1tj$ivr$1@dont-email.me>
In reply to#115934
Stefan Reuther schrieb:
> Am 23.03.2021 um 19:02 schrieb Klaus von der Heyde:
[Konvertierung von systemd-Servicefile in SysVInit-Script]

>> Wahrscheinlich wird man nur ein Sub-Set unterstützen können, aber viele
>> Daemonen wollen ja nur einfach gestartet werden.
> 
> Sind das dann nicht die, die eh nur ein Start- und ein Stop-Kommando im
> Servicefile stehen haben?

Ja sicher. Ich würde aber dennoch Routineaufgaben automatisieren.

Wenn ich mich recht erinnere, waren die Init-Scripte aber immer auch 
distributionsspezifisch; da gab es je nach Distribution Hilfsfunktionen, 
die man ein-sourcen konnte bzw. sollte.

> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
> ausdrücken lassen.

Könnte ich mich jetzt lange drüber auslassen, ob das sinnvoll ist. 
Daemonen müssen auch damit zurechtkommen, dass »das Netz« mal weg ist, 
die IP-Adresse sich ändert. Und soll man auf einen lokal nicht 
vorhandenen SQL-Server warten, wenn die Konfiguration des Daemonen einen 
auf einem anderen Host spezifiziert?

-- Klaus

[toc] | [prev] | [next] | [standalone]


#115947

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-25 08:16 +0100
Message-ID<s3hdbh$4i8$1@news1.tnib.de>
In reply to#115939
Klaus von der Heyde <asc.soc@freenet.de> wrote:
>Stefan Reuther schrieb:
>> Sind das dann nicht die, die eh nur ein Start- und ein Stop-Kommando im
>> Servicefile stehen haben?
>
>Ja sicher. Ich würde aber dennoch Routineaufgaben automatisieren.
>
>Wenn ich mich recht erinnere, waren die Init-Scripte aber immer auch 
>distributionsspezifisch; da gab es je nach Distribution Hilfsfunktionen, 
>die man ein-sourcen konnte bzw. sollte.

Es gab in den letzten Jahren vor systemd Vereinheitlichungsbemühungen
aus dem LSB-Umfeld, wo man versucht hat, über einheitliche Header eine
Art Dependency-Resolving zu implementieren und die
distributionsspezifischen Ausgaben bei einheitlichem Initscript
wegzuabstrahieren. Schöner Ansatz, aber nicht konsequent genug
durchgetrieben. In einem initscript hat man einfach zu viele
Freiheiten um das über die ganez Distribution hindurch einheitlich
treiben zu können. Das scheitert insbesondere dann, wenn die
Maintainer der einzelnen Pakete Freiwillige sind und sich deswegen
gewisse Freiheiten einfordern.

>> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
>> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
>> ausdrücken lassen.
>
>Könnte ich mich jetzt lange drüber auslassen, ob das sinnvoll ist. 
>Daemonen müssen auch damit zurechtkommen, dass »das Netz« mal weg ist, 
>die IP-Adresse sich ändert.

Tun sie halt nicht. Jedenfalls dann nicht, wenn man ihnen, wie in
meinem Geschäft üblich, die IP-Adresse einkonfiguriert auf der sie zu
lauschen haben. Wenn der DNS-Server auf fec0:0:0:ffff::1 konfiguriert
ist und die Addresse beim Start des Daemons noch tentative ist, läuft
halt danach der DNS-Server nicht auf dieser Adresse.

Da kann sich die Systemd-Welt auf den Kopf stellen und fünfmal sagen
"modern daemons do react to system changes" und "you're holding it
wrong", das interessiert ISC nicht die Bohne und ich verstehe voll und
ganz, dass ein auf Portabilität programmierter Daemon sich diese
Linux-Abhängigkeit nicht nachimplementiert nur weil ein arrogantes
initsystem es so will.

>Und soll man auf einen lokal nicht 
>vorhandenen SQL-Server warten, wenn die Konfiguration des Daemonen einen 
>auf einem anderen Host spezifiziert?

Wenn auf einen lokal nicht vorhandenen SQL-Server gewartet wird, dann
ist das ein Konfigurationsfehler. Der sollte sich z.B. durch eine
verlängerte Bootzeit und eine failed unit (die man sich mit systemctl
--failed anzeigen lassen kann - alleine für diese Möglichkeit liebe
ich systemd) offenbaren und dann behoben werden.

|[5/5111]mh@drop:~ $ grep --context=4 failed .bash_profile 
|if [ -x "$(which systemctl)" ] && [ "$(systemctl --version | head -n 1)" != "systemd 215" ]; then
|  if ! systemctl --quiet is-system-running; then
|    echo "systemctl is-system-running returns non-zero and prints:"
|    systemctl is-system-running
|    systemctl --failed
|  fi
|fi
|
|if [ -r /var/log/cron-apt/lastfullmessage ]; then
|[6/5112]mh@drop:~ $ 

Grüße
Ma "die Prüfung auf den uralten systemd 215 kann ich da wirklich mal
rausnehmen" "warum habe ich da which und nicht command -v verwendet?"
rc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115950

FromBastian Blank <usenet@waldi.eu.org>
Date2021-03-25 07:25 +0000
Message-ID<slrns5oemq.n9q.usenet@mobilewave.waldi.eu.org>
In reply to#115934
Stefan Reuther wrote:
> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
> ausdrücken lassen.

"Braucht Netz" ist halt eine hart zu definierende Anforderung. Braucht
es eine IP?  Einen funktionierenden DNS? Vielleicht Internet?

Bastian

[toc] | [prev] | [next] | [standalone]


#115955

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-25 08:56 +0100
Message-ID<s3hfmv$a2s$1@news1.tnib.de>
In reply to#115950
Bastian Blank <usenet@waldi.eu.org> wrote:
>Stefan Reuther wrote:
>> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
>> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
>> ausdrücken lassen.
>
>"Braucht Netz" ist halt eine hart zu definierende Anforderung. Braucht
>es eine IP?  Einen funktionierenden DNS? Vielleicht Internet?

Und wie definiert systemd das? Wer ein network-online.target
definiert, sollte sich vielleicht darüber im Klaren sein was das
bedeutet.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


#115956

FromPaul Muster <exp-311221@news.muster.net>
Date2021-03-25 09:09 +0100
Message-ID<g3ttih-r7h.ln1@news.muster.net>
In reply to#115955
On 25.03.21 08:56, Marc Haber wrote:
> Bastian Blank <usenet@waldi.eu.org> wrote:
>> Stefan Reuther wrote:

>>> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
>>> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
>>> ausdrücken lassen.
>>
>> "Braucht Netz" ist halt eine hart zu definierende Anforderung. Braucht
>> es eine IP?  Einen funktionierenden DNS? Vielleicht Internet?
> 
> Und wie definiert systemd das? Wer ein network-online.target
> definiert, sollte sich vielleicht darüber im Klaren sein was das
> bedeutet.

Ist systemd nicht hervorragend dokumentiert und man muss die Doku nur lesen?


mfG Paul

[toc] | [prev] | [next] | [standalone]


#115960

FromThomas Noll <-_tn_-@web.de>
Date2021-03-25 09:45 +0000
Message-ID<s3hm3c$t44$1@news2.open-news-network.org>
In reply to#115956
Am Thu, 25 Mar 2021 09:09:52 +0100 schrieb Paul Muster:

> On 25.03.21 08:56, Marc Haber wrote:
>> Bastian Blank <usenet@waldi.eu.org> wrote:
>>> Stefan Reuther wrote:
> 
>>>> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
>>>> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
>>>> ausdrücken lassen.
>>>
>>> "Braucht Netz" ist halt eine hart zu definierende Anforderung. Braucht
>>> es eine IP?  Einen funktionierenden DNS? Vielleicht Internet?
>> 
>> Und wie definiert systemd das? Wer ein network-online.target
>> definiert, sollte sich vielleicht darüber im Klaren sein was das
>> bedeutet.
> 
> Ist systemd nicht hervorragend dokumentiert und man muss die Doku nur lesen?

Jepp.

FTFM:
---
This target unit is intended to pull in
a service that delays further execution until the network is
sufficiently set up. What precisely this requires is left to the
implementation of the network managing service.
---

D.h. die Definition des Targets liegt in der Verantwortung des Admins,
der sich wohl üblicherweise auf seine Distribution verlässt.



[toc] | [prev] | [next] | [standalone]


#115962

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2021-03-25 13:41 +0100
Message-ID<s3i0em$buk$1@news1.tnib.de>
In reply to#115956
Paul Muster <exp-311221@news.muster.net> wrote:
>On 25.03.21 08:56, Marc Haber wrote:
>> Bastian Blank <usenet@waldi.eu.org> wrote:
>>> Stefan Reuther wrote:
>
>>>> Die komplizierten Sachen sind doch genau die Abhängigkeiten ("braucht
>>>> Netz", "braucht Mysql") die sich in einem Initscript nicht wirklich
>>>> ausdrücken lassen.
>>>
>>> "Braucht Netz" ist halt eine hart zu definierende Anforderung. Braucht
>>> es eine IP?  Einen funktionierenden DNS? Vielleicht Internet?
>> 
>> Und wie definiert systemd das? Wer ein network-online.target
>> definiert, sollte sich vielleicht darüber im Klaren sein was das
>> bedeutet.
>
>Ist systemd nicht hervorragend dokumentiert und man muss die Doku nur lesen?

An dieser Stelle steht da sinngemäß "entscheide Du und implementiere
es so wie es Dir passt" mit dem Default "wir knallen dem Kernel ein
paar Netlink-Events vor den Latz und machen weiter, hauptsache
schnell".

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]


Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc


csiph-web