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

Groups > linux.debian.user > #206072 > unrolled thread

systemd error

Back to article view | Back to linux.debian.user

Contents

  systemd error Default User <hunguponcontent@gmail.com> - 2019-03-08 22:20 +0100
    Re: systemd error Reco <recoverym4n@enotuniq.net> - 2019-03-09 08:50 +0100
      Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-10 03:50 +0100
        Re: systemd error Reco <recoverym4n@enotuniq.net> - 2019-03-10 08:40 +0100
          Re: systemd error Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2019-03-10 12:10 +0100
            Re: systemd error Curt <curty@free.fr> - 2019-03-10 14:30 +0100
              Re: systemd error Reco <recoverym4n@enotuniq.net> - 2019-03-10 16:30 +0100
                Re: systemd error Curt <curty@free.fr> - 2019-03-10 17:50 +0100
                Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-10 17:50 +0100
                  Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-10 20:50 +0100
                    Re: systemd error Reco <recoverym4n@enotuniq.net> - 2019-03-10 21:10 +0100
                      Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-11 05:00 +0100
                        Re: systemd error Sven Hartge <sven@svenhartge.de> - 2019-03-11 08:50 +0100
                          Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-11 13:50 +0100
                            Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-13 06:00 +0100
                              Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-13 06:10 +0100
                              Re: systemd error <tomas@tuxteam.de> - 2019-03-13 09:50 +0100
                              Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-13 14:30 +0100
                              Re: systemd error Dan Ritter <dsr@randomstring.org> - 2019-03-13 16:10 +0100
                                Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-13 19:20 +0100
                                Re: systemd error deloptes <deloptes@gmail.com> - 2019-03-13 21:30 +0100
                                  Re: systemd error <tomas@tuxteam.de> - 2019-03-13 22:00 +0100
    Re: systemd error Curt <curty@free.fr> - 2019-03-09 10:30 +0100
      Re: systemd error Default User <hunguponcontent@gmail.com> - 2019-03-10 03:40 +0100
        Re: systemd error Curt <curty@free.fr> - 2019-03-10 10:40 +0100
          Re: systemd error Cindy-Sue Causey <butterflybytes@gmail.com> - 2019-03-10 15:10 +0100

Page 1 of 2  [1] 2  Next page →

#206072 — systemd error

[Multipart message — attachments visible in raw view] — view raw

Hi.  Got a (minor) systemd problem.

Running:
- 64-bit X86 computer.
- Debian Unstable, fully updated.
- Cinnamon desktop environment.
- stock setup, nothing exotic.

Boot up okay.
Internet connectivity okay (wifi, using Network Manager). No apparent
problems.

But,

----------

doofus@doofus:~$ sudo systemctl status
[sudo] password for doofus:
● doofus
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
. . .

----------
: (
----------

doofus@doofus:~$ sudo systemctl
[sudo] password for doofus:
  UNIT                                                LOAD   ACTIVE SUB
   DESCRIPTION
  proc-sys-fs-binfmt_misc.automount                   loaded active
waiting   Arbitrary Executable File
. . .
● minissdpd.service                                   loaded failed failed
  keep memory of all UPnP d
. . .

----------

doofus@doofus:~$ sudo systemctl is-enabled minissdpd.service
enabled

----------

doofus@doofus:~$ sudo systemctl stop minissdpd.service

----------

doofus@doofus:~$ sudo systemctl start minissdpd.service

----------

doofus@doofus:~$ sudo systemctl status minissdpd.service
● minissdpd.service - keep memory of all UPnP devices that announced
themselves
   Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled; vendor
preset: enabled)
   Active: active (running) since Fri 2019-03-08 15:39:02 EST; 2min 14s ago
     Docs: man:minissdpd(1)
  Process: 3683 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $M
 Main PID: 3684 (minissdpd)
    Tasks: 1 (limit: 4915)
   Memory: 400.0K
   CGroup: /system.slice/minissdpd.service
           └─3684 /usr/sbin/minissdpd -i enp7s0 -i wlp6s0

Mar 08 15:39:02 doofus systemd[1]: Starting keep memory of all UPnP devices
that announced themselves.
Mar 08 15:39:02 doofus systemd[1]: Started keep memory of all UPnP devices
that announced themselves.

----------

doofus@doofus:~$ sudo systemctl status
● doofus
    State: running
     Jobs: 0 queued
   Failed: 0 units

----------

So, although the minissdpd.service unit is enables, it does not start
automatically at boot, but will start manually using systemctl start/stop.

My system "seems" to work okay (I didn't know there was a systemd problem
until I checked systemctl status out of curiosity. But I really would like
to find out why this unit does not autostart on bootup, and how to fix
that.

Ideas?

[toc] | [next] | [standalone]

#206074

	Hi.

On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> Hi.  Got a (minor) systemd problem.
...
>            └─3684 /usr/sbin/minissdpd -i enp7s0 -i wlp6s0
...
> So, although the minissdpd.service unit is enables, it does not start
> automatically at boot, but will start manually using systemctl start/stop.

What is most likely happening at boot is that systemd tries to start
minissdpd before configuring interfaces enp7s0 and wlp6s0.
So it fails at boot, but works for manual restart because by then you
have both enp7s0 and wlp6s0 up and running.
Adding a dependency in the form of:

[Unit]
After=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
Requires=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device

Should help with the issue.

Reco

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

#206088

[Multipart message — attachments visible in raw view] — view raw

On Sat, Mar 9, 2019 at 2:45 AM Reco <recoverym4n@enotuniq.net> wrote:

>         Hi.
>
> On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> > Hi.  Got a (minor) systemd problem.
> ...
> >            └─3684 /usr/sbin/minissdpd -i enp7s0 -i wlp6s0
> ...
> > So, although the minissdpd.service unit is enables, it does not start
> > automatically at boot, but will start manually using systemctl
> start/stop.
>
> What is most likely happening at boot is that systemd tries to start
> minissdpd before configuring interfaces enp7s0 and wlp6s0.
> So it fails at boot, but works for manual restart because by then you
> have both enp7s0 and wlp6s0 up and running.
> Adding a dependency in the form of:
>
> [Unit]
> After=sys-subsystem-net-devices-enp7s0.device
> sys-subsystem-net-devices-wlp6s0.device
> Requires=sys-subsystem-net-devices-enp7s0.device
> sys-subsystem-net-devices-wlp6s0.device
>
> Should help with the issue.
>
> Reco
>


Hi, Reco.
Thanks for the reply and information.

Since I know very little about systemd, may I ask, should:

[Unit]
After=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device
Requires=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device

be appended to an existing .service or .target file, or should a new
.service or .target file be created with these contents? And if a new file
is needed, what should it be named, and in what directory should it be
placed?

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

#206089

	Hi.

On Sat, Mar 09, 2019 at 09:27:35PM -0500, Default User wrote:
> On Sat, Mar 9, 2019 at 2:45 AM Reco <recoverym4n@enotuniq.net> wrote:
> >
> > On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> > > Hi.  Got a (minor) systemd problem.
> > ...
> > >            └─3684 /usr/sbin/minissdpd -i enp7s0 -i wlp6s0
> > ...
> > > So, although the minissdpd.service unit is enables, it does not start
> > > automatically at boot, but will start manually using systemctl
> > start/stop.
> >
> > What is most likely happening at boot is that systemd tries to start
> > minissdpd before configuring interfaces enp7s0 and wlp6s0.
> > So it fails at boot, but works for manual restart because by then you
> > have both enp7s0 and wlp6s0 up and running.
> > Adding a dependency in the form of:
> >
> > [Unit]
> > After=sys-subsystem-net-devices-enp7s0.device
> > sys-subsystem-net-devices-wlp6s0.device
> > Requires=sys-subsystem-net-devices-enp7s0.device
> > sys-subsystem-net-devices-wlp6s0.device
> 
> Hi, Reco.
> Thanks for the reply and information.
> 
> Since I know very little about systemd, may I ask, should:
> 
> [Unit]
> After=sys-subsystem-net-devices-enp7s0.device
> sys-subsystem-net-devices-wlp6s0.device
> Requires=sys-subsystem-net-devices-enp7s0.device
> sys-subsystem-net-devices-wlp6s0.device
> 
> be appended to an existing .service or .target file, or should a new
> .service or .target file be created with these contents? And if a new file
> is needed, what should it be named, and in what directory should it be
> placed?

To do it proper systemd way, you should do the following:

# directory name is crucial
mkdir /etc/systemd/system/minissdpd.service.d
# file name is not important
cat > /etc/systemd/system/minissdpd.service.d/override.conf << EOF
[Unit]
After=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
Requires=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
EOF

systemctl daemon-reload

Just to be free of the formatting errors, you should create one directory,
and add three lines to one file inside it.

Reco

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

#206092

On 10/03/2019 04:20, Reco wrote:
> On Sat, Mar 09, 2019 at 09:27:35PM -0500, Default User wrote:
>> Hi, Reco.
>> Thanks for the reply and information.
>>
>> Since I know very little about systemd, may I ask, should:
>>
>> [Unit]
>> After=sys-subsystem-net-devices-enp7s0.device
>> sys-subsystem-net-devices-wlp6s0.device
>> Requires=sys-subsystem-net-devices-enp7s0.device
>> sys-subsystem-net-devices-wlp6s0.device
>>
>> be appended to an existing .service or .target file, or should a new
>> .service or .target file be created with these contents? And if a new file
>> is needed, what should it be named, and in what directory should it be
>> placed?
> 
> To do it proper systemd way, you should do the following:
> 
> # directory name is crucial
> mkdir /etc/systemd/system/minissdpd.service.d
> # file name is not important
> cat > /etc/systemd/system/minissdpd.service.d/override.conf << EOF
> [Unit]
> After=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
> Requires=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
> EOF
> 
> systemctl daemon-reload

Or run

systemctl edit minissdpd.service

which will create the file in the appropriate location, open $EDITOR on
it, and run daemon-reload automatically afterwards.


-- 
Everyone is a genius.  It's just that some people are too stupid to
realize it.

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

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

#206097

On 2019-03-10, Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> wrote:
>> 
>> # directory name is crucial
>> mkdir /etc/systemd/system/minissdpd.service.d
>> # file name is not important
>> cat > /etc/systemd/system/minissdpd.service.d/override.conf << EOF
>> [Unit]
>> After=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
>> Requires=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
>> EOF
>> 
>> systemctl daemon-reload
>
> Or run
>
> systemctl edit minissdpd.service
>
> which will create the file in the appropriate location, open $EDITOR on
> it, and run daemon-reload automatically afterwards.
>

I have

 After=network-online.target
 Wants=network-online.target

as per this bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861231


curty@einstein:~$ systemctl cat minissdpd.service
# /lib/systemd/system/minissdpd.service
[Unit]
Description=keep memory of all UPnP devices that announced themselves
Documentation=man:minissdpd(1)
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
EnvironmentFile=/etc/default/minissdpd
ExecStart=/usr/sbin/minissdpd -i $MiniSSDPd_INTERFACE_ADDRESS
PIDFile=/var/run/minissdpd.pid

[Install]

Perhaps I'm missing something here.


-- 
“Let us again pretend that life is a solid substance, shaped like a globe,
which we turn about in our fingers. Let us pretend that we can make out a plain
and logical story, so that when one matter is despatched--love for instance--
we go on, in an orderly manner, to the next.” - Virginia Woolf, The Waves

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

#206105

	Hi.

On Sun, Mar 10, 2019 at 01:03:47PM -0000, Curt wrote:
> On 2019-03-10, Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> wrote:
> >> 
> >> # directory name is crucial
> >> mkdir /etc/systemd/system/minissdpd.service.d
> >> # file name is not important
> >> cat > /etc/systemd/system/minissdpd.service.d/override.conf << EOF
> >> [Unit]
> >> After=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
> >> Requires=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6s0.device
> >> EOF
> >> 
> >> systemctl daemon-reload
> >
> > Or run
> >
> > systemctl edit minissdpd.service
> >
> > which will create the file in the appropriate location, open $EDITOR on
> > it, and run daemon-reload automatically afterwards.
> >
> 
> I have
> 
>  After=network-online.target
>  Wants=network-online.target
> 
> as per this bug report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861231

That's good for listening INADDR_ANY, but it's not sufficient in this
particular case.


> Perhaps I'm missing something here.

network-online.target does not guarantee that specific network
interfaces will be present.
For instance, enp7s0 can be configured instantly (static IP assignment),
wlp6s0 can lag behind it (dhcp assignment).

Reco

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

#206112

On 2019-03-10, Reco <recoverym4n@enotuniq.net> wrote:
>> 
>> I have
>> 
>>  After=network-online.target
>>  Wants=network-online.target
>> 
>> as per this bug report:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861231
>
> That's good for listening INADDR_ANY, but it's not sufficient in this
> particular case.
>
>
>> Perhaps I'm missing something here.
>
> network-online.target does not guarantee that specific network
> interfaces will be present.
> For instance, enp7s0 can be configured instantly (static IP assignment),
> wlp6s0 can lag behind it (dhcp assignment).

I thought it might have something to do with the fact that were two network
interfaces but then wondered what the following was for, in that case:

 ExecStart=/usr/sbin/minissdpd -i $MiniSSDPd_INTERFACE_ADDRESS

Maybe not for what we need here.

> Reco
>
>


-- 
“Let us again pretend that life is a solid substance, shaped like a globe,
which we turn about in our fingers. Let us pretend that we can make out a plain
and logical story, so that when one matter is despatched--love for instance--
we go on, in an orderly manner, to the next.” - Virginia Woolf, The Waves

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

#206113

[Multipart message — attachments visible in raw view] — view raw

On Sun, Mar 10, 2019 at 11:21 AM Reco <recoverym4n@enotuniq.net> wrote:

>         Hi.
>
> On Sun, Mar 10, 2019 at 01:03:47PM -0000, Curt wrote:
> > On 2019-03-10, Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> wrote:
> > >>
> > >> # directory name is crucial
> > >> mkdir /etc/systemd/system/minissdpd.service.d
> > >> # file name is not important
> > >> cat > /etc/systemd/system/minissdpd.service.d/override.conf << EOF
> > >> [Unit]
> > >> After=sys-subsystem-net-devices-enp7s0.device
> sys-subsystem-net-devices-wlp6s0.device
> > >> Requires=sys-subsystem-net-devices-enp7s0.device
> sys-subsystem-net-devices-wlp6s0.device
> > >> EOF
> > >>
> > >> systemctl daemon-reload
> > >
> > > Or run
> > >
> > > systemctl edit minissdpd.service
> > >
> > > which will create the file in the appropriate location, open $EDITOR on
> > > it, and run daemon-reload automatically afterwards.
> > >
> >
> > I have
> >
> >  After=network-online.target
> >  Wants=network-online.target
> >
> > as per this bug report:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861231
>
> That's good for listening INADDR_ANY, but it's not sufficient in this
> particular case.
>
>
> > Perhaps I'm missing something here.
>
> network-online.target does not guarantee that specific network
> interfaces will be present.
> For instance, enp7s0 can be configured instantly (static IP assignment),
> wlp6s0 can lag behind it (dhcp assignment).
>
> Reco
>



So . . .

I did:
sudo systemctl edit minissdpd.service
entering this:

[Unit]
After=sys-subsystem-net-devices-enp7s0.device sys-subsystem-net-devices-wlp6
s0.device
Requires=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device

It created: /etc/systemd/system/minissdpd.service.d/override.conf:

doofus@doofus:~$ sudo ls
/etc/systemd/system/minissdpd.service.d/override.conf
-rw-r--r-- 1 root root 182 Mar 10 11:23
/etc/systemd/system/minissdpd.service.d/override.conf

doofus@doofus:~$ sudo cat
/etc/systemd/system/minissdpd.service.d/override.conf
[Unit]
After=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device
Requires=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device

But it did not start minissdpd.

I did:
sudo systemctl daemon-reload

But itdid not start minissdpd.

I rebooted.

But it did not start minissdpd.

Grrr . . .

Here is the minissdpd .service file:

doofus@doofus:~$ sudo ls /lib/systemd/system/minissdpd.service
-rw-r--r-- 1 root root 418 Feb 27 22:13
/lib/systemd/system/minissdpd.service

doofus@doofus:~$ sudo cat /lib/systemd/system/minissdpd.service
[Unit]
Description=keep memory of all UPnP devices that announced themselves
Documentation=man:minissdpd(1)
After=network-online.target

[Service]
Type=forking
EnvironmentFile=/etc/default/minissdpd
ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS
PrivateTmp=yes
LimitNOFILE=20
LimitNPROC=5
PIDFile=/run/minissdpd.pid

[Install]
WantedBy=multi-user.target

So, should I try manually editing /lib/systemd/system/minissdpd.service?

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

#206129

[Multipart message — attachments visible in raw view] — view raw

On Sun, Mar 10, 2019 at 1:45 PM Eduardo M KALINOWSKI <
eduardo@kalinowski.com.br> wrote:

> On 10/03/2019 13:25, Default User wrote:
>
> So, should I try manually editing /lib/systemd/system/minissdpd.service?
>
> If you do that, you'll lose changes the next time the package is upgraded.
>
> To see if systemd is seeing your add-in file, use 'systemctl cat
> minissdpd.service'. It should list your file and it's contents.
>
>
> --
> Soldiers who wish to be a hero
> Are practically zero,
> But those who wish to be civilians,
> They run into the millions.
>
> Eduardo M KALINOWSKIeduardo@kalinowski.com.br
>
>

Well,

 doofus@doofus:~$ ls /lib/systemd/system/minissdpd.service
-rw-r--r-- 1 root root 418 Feb 27 22:13
/lib/systemd/system/minissdpd.service


doofus@doofus:~$ sudo cat /lib/systemd/system/minissdpd.service
[Unit]
Description=keep memory of all UPnP devices that announced themselves
Documentation=man:minissdpd(1)
After=network-online.target

[Service]
Type=forking
EnvironmentFile=/etc/default/minissdpd
ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS
PrivateTmp=yes
LimitNOFILE=20
LimitNPROC=5
PIDFile=/run/minissdpd.pid

[Install]
WantedBy=multi-user.target

----------
But . . .
----------

doofus@doofus:~$ systemctl cat minissdpd.service
# /lib/systemd/system/minissdpd.service
[Unit]
Description=keep memory of all UPnP devices that announced themselves
Documentation=man:minissdpd(1)
After=network-online.target

[Service]
Type=forking
EnvironmentFile=/etc/default/minissdpd
ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_O
PrivateTmp=yes
LimitNOFILE=20
LimitNPROC=5
PIDFile=/run/minissdpd.pid

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/minissdpd.service.d/override.conf
[Unit]
After=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device
Requires=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device

----------

So, the file  /lib/systemd/system/minissdpd.service is unchanged since Feb
27 22:13.  It does NOT appear to include the contents of, or even refer
to,  /etc/systemd/system/minissdpd.service.d/override.conf, dated Mar 10
11:23.

Yet systemctl cat minissdpd.service DOES appear to reference
/etc/systemd/system/minissdpd.service.d/override.conf!

???

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

#206132

	Hi.

On Sun, Mar 10, 2019 at 03:30:46PM -0400, Default User wrote:
> So, the file  /lib/systemd/system/minissdpd.service is unchanged since Feb
> 27 22:13.  It does NOT appear to include the contents of, or even refer
> to,  /etc/systemd/system/minissdpd.service.d/override.conf, dated Mar 10
> 11:23.
> 
> Yet systemctl cat minissdpd.service DOES appear to reference
> /etc/systemd/system/minissdpd.service.d/override.conf!

That does not simplify things.
Some sections of systemd unit file are magic, you cannot override them
like this.
Time for plan B then.

Remove /etc/systemd/system/minissdpd.service.d/override.conf
Copy /lib/systemd/system/minissdpd.service to
/etc/systemd/system/minissdpd.service.
Edit the resulting file.

Reco

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

#206141

[Multipart message — attachments visible in raw view] — view raw

Okay, I give up.

I have literally spent almost all day trying to solve this.  I tried and
tried, everything I could think of. But to no avail. So I quit.

I will just have to either ignore the problem and pretend it doesn't exist,
or just purge the minissdpd package completely, and hope nothing really
needs it. Decisions, decisions . . .

Anyway I do want to thank those who tried to help me with this.  I really
do appreciate it.

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

#206144

Default User <hunguponcontent@gmail.com> wrote:

> I will just have to either ignore the problem and pretend it doesn't
> exist, or just purge the minissdpd package completely, and hope
> nothing really needs it. Decisions, decisions . . .

"Nothing really needs it." is the answer here. It speeds up some
operations in some contexts, but nothing noticable for the average user
in general.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

#206149

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 11, 2019, 03:45 Sven Hartge <sven@svenhartge.de> wrote:

> Default User <hunguponcontent@gmail.com> wrote:
>
> > I will just have to either ignore the problem and pretend it doesn't
> > exist, or just purge the minissdpd package completely, and hope
> > nothing really needs it. Decisions, decisions . . .
>
> "Nothing really needs it." is the answer here. It speeds up some
> operations in some contexts, but nothing noticable for the average user
> in general.
>
> Grüße,
> Sven.
>
> --
> Sigmentation fault. Core dumped.
>



Okay.
Thank you, Sven.

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

#206207

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 12, 2019, 04:49 Ivan Ivanov <qmastery16@gmail.com> wrote:

> Well, I know a good solution that will work 100%: switch from Debian
> to Devuan to avoid this SystemD. sadly Debian does not provide the
> init system freedom, but if you'd switch to its' brother distribution
> (Devuan) it still provides all the benefits of Debian + the freedom
> from SystemD.
>



Thanks for the suggestion, Ivan.

Actually, I had high hopes for Devuan. But I am afraid that it's just too
little, too late.

The cancer of systemd has metastasized too far and the GNU/Linux patent is
terminally ill.

How sad that once again, the bad guys won because good men did nothing.

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

#206208

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 13, 2019, 00:38 Default User <hunguponcontent@gmail.com> wrote:

>
>
> On Tue, Mar 12, 2019, 04:49 Ivan Ivanov <qmastery16@gmail.com> wrote:
>
>> Well, I know a good solution that will work 100%: switch from Debian
>> to Devuan to avoid this SystemD. sadly Debian does not provide the
>> init system freedom, but if you'd switch to its' brother distribution
>> (Devuan) it still provides all the benefits of Debian + the freedom
>> from SystemD.
>>
>
>
>
> Thanks for the suggestion, Ivan.
>
> Actually, I had high hopes for Devuan. But I am afraid that it's just too
> little, too late.
>
> The cancer of systemd has metastasized too far and the GNU/Linux patent is
> terminally ill.
>
> How sad that once again, the bad guys won because good men did nothing.
>
>


Yes, it was supposed to say "patient", not "patent".

It's the sentiment that counts.



>

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

#206215

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 13, 2019 at 12:38:48AM -0400, Default User wrote:

[...]

> The cancer of systemd has metastasized too far and the GNU/Linux patent is
> terminally ill.

MikeeeUSA at it again. We don't need that.

-- t

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

#206229

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 13, 2019, 04:06 Ivan Ivanov <qmastery16@gmail.com> wrote:

> On Mar 13, 2019, 07:54, Default User <hunguponcontent@gmail.com> wrote:
> >
> > On Tue, Mar 12, 2019, 04:49 Ivan Ivanov <qmastery16@gmail.com> wrote:
> >>
> >> Well, I know a good solution that will work 100%: switch from Debian
> >> to Devuan to avoid this SystemD. sadly Debian does not provide the
> >> init system freedom, but if you'd switch to its' brother distribution
> >> (Devuan) it still provides all the benefits of Debian + the freedom
> >> from SystemD.
> >
> > Thanks for the suggestion, Ivan.
> >
> > Actually, I had high hopes for Devuan. But I am afraid that it's just
> too little, too late.
> >
> > The cancer of systemd has metastasized too far and the GNU/Linux patient
> is terminally ill.
> >
> > How sad that once again, the bad guys won because good men did nothing.
> >
>
> Don't give up friend, we have not lost! In addition to Devuan, there
> are truly awesome no-SystemD distributions:
>
> Artix (arch-based, with OpenRC), Nutyx (independent, SysVinit), Void
> Linux (independent, with runit) - they have very fresh kernels and
> packages while also being relatively stable! Really good if you want
> the fresh drivers and mesa for gaming.
> MX Linux - if you want a popular Debian-based no-SystemD distro that
> actually surpassed Debian in popularity! (according to Distrowatch)
>
> Just telling you that there are still enough oasises in this GNU/Linux
> desert ;-)
>
> I actually hope that someone will combine the features of my favorite
> distros: something no-SystemD mentioned above as the base + QubesOS
> hardcore virtualization for great security + ideology of Free Software
> Foundation endorsed distros (remove all the closed source binaries
> from a distribution, e.g. because they could contain the backdoors).
> This is a distro of my dreams
>




Good luck.

May you keep the innocence and optimism of youth !

: )

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

#206230

Default User wrote: 
> On Tue, Mar 12, 2019, 04:49 Ivan Ivanov <qmastery16@gmail.com> wrote:
> 
> > Well, I know a good solution that will work 100%: switch from Debian
> > to Devuan to avoid this SystemD. sadly Debian does not provide the
> > init system freedom, but if you'd switch to its' brother distribution
> > (Devuan) it still provides all the benefits of Debian + the freedom
> > from SystemD.
> >
> 
> 
> 
> Thanks for the suggestion, Ivan.
> 
> Actually, I had high hopes for Devuan. But I am afraid that it's just too
> little, too late.
> 
> The cancer of systemd has metastasized too far and the GNU/Linux patent is
> terminally ill.
> 
> How sad that once again, the bad guys won because good men did nothing.

In point of fact:

- I run several hundred Debian stretch systems without systemd
  running as init, or doing very much otherwise.

  "apt install sysvinit-core" was all that is needed.

- Those are almost all servers, but also includes some desktops.

- The debian-init-diversity mail archives are here:
  http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-March/thread.html
    and you can see that good work is being done on sysvinit,
    startpar, insserv and elogind.

I don't know why this doesn't get more publicity. 

If you are having problems with systemd and they feel intractable,
it's perfectly reasonable to go back to sysvinit, and it's only a little
work to move to openrc and a moderate amount to use completely different
init systems.

-dsr-

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

#206233

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 13, 2019, 10:50 Dan Ritter <dsr@randomstring.org> wrote:

> Default User wrote:
> > On Tue, Mar 12, 2019, 04:49 Ivan Ivanov <qmastery16@gmail.com> wrote:
> >
> > > Well, I know a good solution that will work 100%: switch from Debian
> > > to Devuan to avoid this SystemD. sadly Debian does not provide the
> > > init system freedom, but if you'd switch to its' brother distribution
> > > (Devuan) it still provides all the benefits of Debian + the freedom
> > > from SystemD.
> > >
> >
> >
> >
> > Thanks for the suggestion, Ivan.
> >
> > Actually, I had high hopes for Devuan. But I am afraid that it's just too
> > little, too late.
> >
> > The cancer of systemd has metastasized too far and the GNU/Linux patent
> is
> > terminally ill.
> >
> > How sad that once again, the bad guys won because good men did nothing.
>
> In point of fact:
>
> - I run several hundred Debian stretch systems without systemd
>   running as init, or doing very much otherwise.
>
>   "apt install sysvinit-core" was all that is needed.
>
> - Those are almost all servers, but also includes some desktops.
>
> - The debian-init-diversity mail archives are here:
>
> http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-March/thread.html
>     and you can see that good work is being done on sysvinit,
>     startpar, insserv and elogind.
>
> I don't know why this doesn't get more publicity.
>
> If you are having problems with systemd and they feel intractable,
> it's perfectly reasonable to go back to sysvinit, and it's only a little
> work to move to openrc and a moderate amount to use completely different
> init systems.
>
> -dsr-
>



Noted.

Thanks for the pointers, Dan.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web