Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#819314: procps: [sysctl] Missing dependency when used with systemd
102 views
Skip to first unread message
Martin Mares
Mar 26, 2016, 11:20:03 AM3/26/16
to
Package: procps
Version: 2:3.3.9-9
Severity: normal
With sysvinit, the init script for procps ensures that sysctl's
are set before networking is started (via X-Start-Before: $network).
When run with systemd, procps.service does not have such dependency.
Since system startup is highly parallel, there is a race condition:
sometimes network interfaces are initialized before net.ipv6.conf.default.*
is set.
If the new behavior is considered better for some reason,
at least the difference should be clearly documented.
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.16-kam (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages procps depends on:
ii initscripts 2.88dsf-59
ii libc6 2.19-18+deb8u3
ii libncurses5 5.9+20140913-1+b1
ii libncursesw5 5.9+20140913-1+b1
ii libprocps3 2:3.3.9-9
ii libtinfo5 5.9+20140913-1+b1
ii lsb-base 4.1+Debian13+nmu1
Versions of packages procps recommends:
ii psmisc 22.21-2
procps suggests no packages.
-- no debconf information
Version: 2:3.3.9-9
Severity: normal
With sysvinit, the init script for procps ensures that sysctl's
are set before networking is started (via X-Start-Before: $network).
When run with systemd, procps.service does not have such dependency.
Since system startup is highly parallel, there is a race condition:
sometimes network interfaces are initialized before net.ipv6.conf.default.*
is set.
If the new behavior is considered better for some reason,
at least the difference should be clearly documented.
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.16-kam (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages procps depends on:
ii initscripts 2.88dsf-59
ii libc6 2.19-18+deb8u3
ii libncurses5 5.9+20140913-1+b1
ii libncursesw5 5.9+20140913-1+b1
ii libprocps3 2:3.3.9-9
ii libtinfo5 5.9+20140913-1+b1
ii lsb-base 4.1+Debian13+nmu1
Versions of packages procps recommends:
ii psmisc 22.21-2
procps suggests no packages.
-- no debconf information
Craig Small
Mar 26, 2016, 11:40:02 PM3/26/16
to
reassign 819314 systemd
thankyou
When you run systemd the sysctl unit is not the one from procps but is a program from systemd itself. systemctl status procps probably mentions /lib/systemd/systemd-sysctl
It sounds like you have hit another odd difference between the two inits.
- Craig
Michael Biebl
Mar 27, 2016, 4:50:05 AM3/27/16
to
Control: tags -1 + moreinfo
On Sat, 26 Mar 2016 16:03:24 +0100 Martin Mares <m...@ucw.cz> wrote:
> Package: procps
> Version: 2:3.3.9-9
> Severity: normal
>
> With sysvinit, the init script for procps ensures that sysctl's
> are set before networking is started (via X-Start-Before: $network).
>
> When run with systemd, procps.service does not have such dependency.
> Since system startup is highly parallel, there is a race condition:
> sometimes network interfaces are initialized before net.ipv6.conf.default.*
> is set.
>
Are you sure?
networking.service has
> After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
This makes sure that networking.service, which deals with type auto
interfaces, is started after systemd-sysctl.service.
And for hotplugged devices
/lib/udev/rules.d/99-systemd.rules contains
> 99-systemd.rules:# Apply sysctl variables to network devices (and only to those) as they appear.
> 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
Can you explain the specific problem you ran into and what configuration
you are using exactly.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
On Sat, 26 Mar 2016 16:03:24 +0100 Martin Mares <m...@ucw.cz> wrote:
> Package: procps
> Version: 2:3.3.9-9
> Severity: normal
>
> With sysvinit, the init script for procps ensures that sysctl's
> are set before networking is started (via X-Start-Before: $network).
>
> When run with systemd, procps.service does not have such dependency.
> Since system startup is highly parallel, there is a race condition:
> sometimes network interfaces are initialized before net.ipv6.conf.default.*
> is set.
>
networking.service has
> After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
This makes sure that networking.service, which deals with type auto
interfaces, is started after systemd-sysctl.service.
And for hotplugged devices
/lib/udev/rules.d/99-systemd.rules contains
> 99-systemd.rules:# Apply sysctl variables to network devices (and only to those) as they appear.
> 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
Can you explain the specific problem you ran into and what configuration
you are using exactly.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Martin Mares
Mar 31, 2016, 11:00:03 AM3/31/16
to
Hello!
> Are you sure?
> networking.service has
> > After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
>
> This makes sure that networking.service, which deals with type auto
> interfaces, is started after systemd-sysctl.service.
On my system (Wheezy recently upgraded to Jessie):
| ● networking.service - LSB: Raise network interfaces.
| Loaded: loaded (/etc/init.d/networking)
| Drop-In: /run/systemd/generator/networking.service.d
| └─50-insserv.conf-$network.conf
| /lib/systemd/system/networking.service.d
| └─network-pre.conf
| Active: active (exited) since Sun 2016-03-20 21:56:51 CET; 1 weeks 3 days ago
/run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf
contains only:
| # Automatically generated by systemd-insserv-generator
|
| [Unit]
| Wants=network.target
| Before=network.target
/lib/systemd/system/networking.service.d/network-pre.conf contains only:
| [Unit]
| After=network-pre.target
No trace of systemd-sysctl.service anywhere.
> And for hotplugged devices
>
> /lib/udev/rules.d/99-systemd.rules contains
> > 99-systemd.rules:# Apply sysctl variables to network devices (and only to those) as they appear.
> > 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
This works for per-interface options, but not for /net/ipv6/conf/default.
(However, I probably should abandon using conf/default anyway, since some
kernel modules are loaded before sysctl is set.)
Martin
> Are you sure?
> networking.service has
> > After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
>
> This makes sure that networking.service, which deals with type auto
> interfaces, is started after systemd-sysctl.service.
| ● networking.service - LSB: Raise network interfaces.
| Loaded: loaded (/etc/init.d/networking)
| Drop-In: /run/systemd/generator/networking.service.d
| └─50-insserv.conf-$network.conf
| /lib/systemd/system/networking.service.d
| └─network-pre.conf
| Active: active (exited) since Sun 2016-03-20 21:56:51 CET; 1 weeks 3 days ago
/run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf
contains only:
| # Automatically generated by systemd-insserv-generator
|
| [Unit]
| Wants=network.target
| Before=network.target
/lib/systemd/system/networking.service.d/network-pre.conf contains only:
| [Unit]
| After=network-pre.target
No trace of systemd-sysctl.service anywhere.
> And for hotplugged devices
>
> /lib/udev/rules.d/99-systemd.rules contains
> > 99-systemd.rules:# Apply sysctl variables to network devices (and only to those) as they appear.
> > 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
(However, I probably should abandon using conf/default anyway, since some
kernel modules are loaded before sysctl is set.)
Martin
Michael Biebl
Dec 15, 2016, 6:40:05 PM12/15/16
to
On Thu, 31 Mar 2016 16:45:40 +0200 Martin Mares <m...@ucw.cz> wrote:
> Hello!
>
> > Are you sure?
> > networking.service has
> > > After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
> >
> > This makes sure that networking.service, which deals with type auto
> > interfaces, is started after systemd-sysctl.service.
>
> On my system (Wheezy recently upgraded to Jessie):
>
> | â— networking.service - LSB: Raise network interfaces.
> Hello!
>
> > Are you sure?
> > networking.service has
> > > After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
> >
> > This makes sure that networking.service, which deals with type auto
> > interfaces, is started after systemd-sysctl.service.
>
> On my system (Wheezy recently upgraded to Jessie):
>
> | Loaded: loaded (/etc/init.d/networking)
> | Drop-In: /run/systemd/generator/networking.service.d
> | └─50-insserv.conf-$network.conf
> | Drop-In: /run/systemd/generator/networking.service.d
> | /lib/systemd/system/networking.service.d
> | └─network-pre.conf
> | Active: active (exited) since Sun 2016-03-20 21:56:51 CET; 1 weeks 3 days ago
>
> /run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf
> contains only:
>
> | # Automatically generated by systemd-insserv-generator
> |
> | [Unit]
> | Wants=network.target
> | Before=network.target
>
> /lib/systemd/system/networking.service.d/network-pre.conf contains only:
>
> | [Unit]
> | After=network-pre.target
>
> No trace of systemd-sysctl.service anywhere.
>
> > And for hotplugged devices
> >
> > /lib/udev/rules.d/99-systemd.rules contains
> > > 99-systemd.rules:# Apply sysctl variables to network devices (and only to those) as they appear.
> > > 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
>
> This works for per-interface options, but not for /net/ipv6/conf/default.
> (However, I probably should abandon using conf/default anyway, since some
> kernel modules are loaded before sysctl is set.)
>
>
Afaics, this is fixed in stretch.
>
> /run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf
> contains only:
>
> | # Automatically generated by systemd-insserv-generator
> |
> | [Unit]
> | Wants=network.target
> | Before=network.target
>
> /lib/systemd/system/networking.service.d/network-pre.conf contains only:
>
> | [Unit]
> | After=network-pre.target
>
> No trace of systemd-sysctl.service anywhere.
>
> > And for hotplugged devices
> >
> > /lib/udev/rules.d/99-systemd.rules contains
> > > 99-systemd.rules:# Apply sysctl variables to network devices (and only to those) as they appear.
> > > 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
>
> This works for per-interface options, but not for /net/ipv6/conf/default.
> (However, I probably should abandon using conf/default anyway, since some
> kernel modules are loaded before sysctl is set.)
>
>
systemd-networkd.service has After=systemd-sysctl.service, so does
ifup@.service and networking.service.
So, question is what to do about this in jessie.
We already ship
/lib/systemd/system/networking.service.d/network-pre.conf in systemd,
containing
[Unit]
After=network-pre.target
We could extend that to include After=systemd-sysctl.service.
It would be cleaner if that was shipped in ifupdown itself, but in
jessie, systemd also provides ifup@.service. Both were mistakes in
hindsight, which I'm not sure is worth fixing retroactively.
Guus, do you have any preference here. Do you want to take over that
file from systemd and make a jessie stable upload?
If not, I'd add the After ordering to the jessie systemd package.
Let me know what you think.
Regards,
Michael
Michael Biebl
Dec 15, 2016, 8:30:03 PM12/15/16
to
Am 16.12.2016 um 00:27 schrieb Michael Biebl:
> Afaics, this is fixed in stretch.
> systemd-networkd.service has After=systemd-sysctl.service, so does
> ifup@.service and networking.service.
The relevant commits in ifupdown are
> Afaics, this is fixed in stretch.
> systemd-networkd.service has After=systemd-sysctl.service, so does
> ifup@.service and networking.service.
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=3c7cf828b4306e5282db7cc1dda33593579175eb
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=117cfa63ed4f3dd3d81d2e09a0903052340e3d18
Guus Sliepen
Dec 16, 2016, 3:10:03 AM12/16/16
to
On Fri, Dec 16, 2016 at 12:27:10AM +0100, Michael Biebl wrote:
> It would be cleaner if that was shipped in ifupdown itself, but in
> jessie, systemd also provides ifup@.service. Both were mistakes in
> hindsight, which I'm not sure is worth fixing retroactively.
>
> Guus, do you have any preference here. Do you want to take over that
> file from systemd and make a jessie stable upload?
> If not, I'd add the After ordering to the jessie systemd package.
If it's the same to you, I think it's safer to keep the ifup@.service in
> It would be cleaner if that was shipped in ifupdown itself, but in
> jessie, systemd also provides ifup@.service. Both were mistakes in
> hindsight, which I'm not sure is worth fixing retroactively.
>
> Guus, do you have any preference here. Do you want to take over that
> file from systemd and make a jessie stable upload?
> If not, I'd add the After ordering to the jessie systemd package.
jessie's systemd package, and just add the After there.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <gu...@debian.org>
Michael Biebl
Dec 17, 2016, 3:30:02 PM12/17/16
to
Am 16.12.2016 um 08:59 schrieb Guus Sliepen:
> On Fri, Dec 16, 2016 at 12:27:10AM +0100, Michael Biebl wrote:
>
>> It would be cleaner if that was shipped in ifupdown itself, but in
>> jessie, systemd also provides ifup@.service. Both were mistakes in
>> hindsight, which I'm not sure is worth fixing retroactively.
>>
>> Guus, do you have any preference here. Do you want to take over that
>> file from systemd and make a jessie stable upload?
>> If not, I'd add the After ordering to the jessie systemd package.
>
> If it's the same to you, I think it's safer to keep the ifup@.service in
> jessie's systemd package, and just add the After there.
>
I actually meant, if you want to take over the
> On Fri, Dec 16, 2016 at 12:27:10AM +0100, Michael Biebl wrote:
>
>> It would be cleaner if that was shipped in ifupdown itself, but in
>> jessie, systemd also provides ifup@.service. Both were mistakes in
>> hindsight, which I'm not sure is worth fixing retroactively.
>>
>> Guus, do you have any preference here. Do you want to take over that
>> file from systemd and make a jessie stable upload?
>> If not, I'd add the After ordering to the jessie systemd package.
>
> If it's the same to you, I think it's safer to keep the ifup@.service in
> jessie's systemd package, and just add the After there.
>
/lib/systemd/system/networking.service.d/network-pre.conf drop-in config
in a jessie upload for ifupdown.
Moving the ifup@.service (+ the udev rule) would be a too invasive
change for stable.
But I guess it's better if we just keep the status quo in jessie and I
simply add the After= ordering to both ifup@.service and
network-pre.conf in the next systemd stable upload.
Speaking of After= ordering, Guus it would be great if you could upload
ifupdown with the fix for [1]. I'm not sure yet when systemd v233 will
be released and if we will have v233 for stretch. But in case we do, it
would be great if ifupdown was already fixed. It would also make
potential systemd backports easier.
Regards,
Michael
[1]
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=3dfd35904faa0c6ee2b8a622796880b71d577924
0 new messages