Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Mantas Mikulėnas]

On Tue, Jul 11, 2017, 22:24 Ian Pilcher  wrote:

> On 07/11/2017 02:58 AM, Lennart Poettering wrote:
> > Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
> > do so. Hence, areyou sure the RA spoken on your network properly
> > indicates that?
>
> Interesting.  I am seeing somewhat different behavior (but note that
> this is systemd-networkd 219 on CentOS 7, which is pretty old).
>
> * On networks with no router advertisements at all, systemd-networkd 219
>will eventually send out dhcp6 solicit packets.
>
> * On a network with router advertisements that include prefix info
>(option 3), systemd-networkd 219 will send dhcp6 solicit packets.
>
> * If the router advertisements on a network do not include any prefix
>information, however, systemd-networkd 219 will never send any dhcp6
>solicit packets and never configure an IPv6 address.
>
> Unfortunately, my ISP's router sends RAs without prefix information.
> (Clients get their addresses via DHCPv6, and are presumably expected to
> simply assume a 64 bit prefix length.)
>
> So it looks like I won't be able to use systemd-networkd to get around
> the dhclient wall clock problem, at least until RHEL/CentOS see an
> updated version of systemd (systemd-networkd 231 does seem to behave
> differently).
>

What global flags do each network's RAs have? If I remember correctly,
there are two, "Managed Addresses" and "Managed Other", which trigger
DHCPv6 – if neither of them is set, that is supposed to mean DHCPv6 is
unneeded.

>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trying to come up with udev rule for USB geographic naming

[Andrei Borzenkov]

12.07.2017 02:53, Paul D. DeRocco пишет:
>> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] 
>>
>>> KERNEL=="midiC*", DRIVERS=="snd-usb-audio", SYMLINK+="midi%k"
>>
>> You probably want %b instead of %k here which should refer to device
>> name matched by DRIVERS.
>>
>> Start with "udevadm test" to verify.
> 
> I tried the following rule:
> 
> ACTION=="add", KERNEL=="midiC*", DRIVERS=="snd-usb-audio", 
> SYMLINK+="snd/midi%b"
> 
> and "udevadm test" complains about an "invalid DRIVERS option". What could be 
> invalid about it?
> 

No idea. Please copy-paste actual command invocation and its output.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-udevd invoked oom-killer

[Cristian Rodríguez]

El 11-07-2017 a las 18:23, WANG Siyuan escribió:
> Hi, all
> systemd-udevd invoked oom-killer during Linux boot. I open debug message
> of systemd-udevd. But I can't find where the problem is. Could anybody
> help me? Thanks very much.

The oom-killer should never be invoked on udev at boot.. either you are
working in very memory constrained device or there is a problem in your
kernel/toolchain/etc build.

At least tell use what distribution are you using if any and/or what
systemd version, you could also disable the oom-killer on
systemd-udev.service..




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trying to come up with udev rule for USB geographic naming

[Paul D. DeRocco]

> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] 
> 
> > KERNEL=="midiC*", DRIVERS=="snd-usb-audio", SYMLINK+="midi%k"
> 
> You probably want %b instead of %k here which should refer to device
> name matched by DRIVERS.
> 
> Start with "udevadm test" to verify.

I tried the following rule:

ACTION=="add", KERNEL=="midiC*", DRIVERS=="snd-usb-audio", SYMLINK+="snd/midi%b"

and "udevadm test" complains about an "invalid DRIVERS option". What could be 
invalid about it?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trying to come up with udev rule for USB geographic naming

[Paul D. DeRocco]

> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] 
> 
> > There is already a symlink
> > "/dev/snd/by-path/platform-3f98.usb-usb-0:1.2:1.0", but 
> > it refers to
> > the useless "controlC1" interface. It also doesn't appear 
> > to be generated
> > by an explicit rule anywhere that might show me what to do.
> 
> It is created by 60-persistent-alsa.rules that explicitly restricts
> processing to controlC*.

Ahah! The systemd man page only mention /usr/lib, /etc, and /run as locations 
for udev/rules.d subdirectories, but apparently there's also one in /lib that's 
full of rules I didn't see.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Florian Weimer]

* Lennart Poettering:

> Apparently, this regressed between this version and
> glibc-2.24-9.fc25.x86_64 hence.

Yes, I backported the fork cache removal to Fedora 25.  There is no
longer a good way to main such a cache in userspace because glibc
cannot intercept anymore all the ways that can change the PID of the
current process because the kernel interfaces for process management
are incredibly rich these days.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Florian Weimer]

* Lennart Poettering:

> This all stems from my experiences with PulseAudio back in the day:
> People do not grok the effect of fork(): it only duplicates the
> invoking thread, not any other threads of the process, moreover all
> data structures are copied as they are, and that's a time bomb really:

These days, the PID can change even without a fork, so the story is a
bit different.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Ian Pilcher]

On 07/11/2017 02:58 AM, Lennart Poettering wrote:

Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?


Interesting.  I am seeing somewhat different behavior (but note that
this is systemd-networkd 219 on CentOS 7, which is pretty old).

* On networks with no router advertisements at all, systemd-networkd 219
  will eventually send out dhcp6 solicit packets.

* On a network with router advertisements that include prefix info
  (option 3), systemd-networkd 219 will send dhcp6 solicit packets.

* If the router advertisements on a network do not include any prefix
  information, however, systemd-networkd 219 will never send any dhcp6
  solicit packets and never configure an IPv6 address.

Unfortunately, my ISP's router sends RAs without prefix information.
(Clients get their addresses via DHCPv6, and are presumably expected to
simply assume a 64 bit prefix length.)

So it looks like I won't be able to use systemd-networkd to get around
the dhclient wall clock problem, at least until RHEL/CentOS see an
updated version of systemd (systemd-networkd 231 does seem to behave
differently).

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Florian Weimer]

* Michael Chapman:

> It's a pity glibc doesn't provide an equivalent for pthread_atfork() 
> outside of the pthread library. Having a notification that a fork has just 
> occurred would allow us to do the PID caching ourselves.

In fact, it does, as a public symbol: __register_atfork.

It's just not really documented, so it lives a bit a vacuum, like the
old __secure_getenv call.  To fix this, we need to make the dynamic
linker disregard sonames when resolving non-interposed versioned
symbols, and then move the definition from libpthread to libc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Auke Kok]

On 07/10/2017 08:23 PM, Ian Pilcher wrote:
> I'm playing using systemd-networkd (rather than the legacy network
> service) on my Banana Pi CentOS 7 firewall.  (See the "Bouncing
> interface once chrony is synced" thread for background.)
> 
> I have "DHCP=yes" in the [Network] section of my WAN interface
> (eth0.256.network):
> 
>  [Match]
>  Name=eth0.256
> 
>  [Network]
>  DHCP=yes
>  IPForward=yes
>  #IPv6AcceptRA=yes - Not supported in v219
> 
>  [DHCP]
>  UseHostname=no
> 
> For some reason, though, only the IPv4 DHCP request is being sent.  I
> have verified with tcpdump that no "dhcp6 solicit" packets are ever
> sent.

I have a "similar" issue: with 'DHCP=both', only an ipv4 address is
obtained, even though my dhcp server is capable of giving other OS's
with e.g. NetworkManager both ipv4 and ipv6 addresses.

Auke


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Tomasz Torcz]

On Tue, Jul 11, 2017 at 05:20:10PM +0200, Lennart Poettering wrote:
> On Tue, 11.07.17 16:55, Tomasz Torcz (to...@pipebreaker.pl) wrote:
> > > Forgot to mention:
> > > 
> > > $ rpm -qa glibc
> > > glibc-2.24-4.fc25.x86_64
> > > 
> > > Apparently, this regressed between this version and
> > > glibc-2.24-9.fc25.x86_64 hence.
> > > 
> > 
> >   From glibc changelog:
> > 
> > * Wed Jun 07 2017 Arjun Shankar  - 2.24-6
> > - Auto-sync with upstream release/2.24/master,
> >   commit 7b60553e360731338631ccdda71590ac5deca137, fixing:
> > - Remove the PID cache  (#1443976)
> 
> I commented on that bug now. It doesn#t really have a proper
> explanation, all it says is that "The glibc PID cache negatively
> interacts with setting up containers and namespaces."...

  Upstream commit has longer rationale:
http://repo.or.cz/glibc.git/commit/c579f48edba88380635ab98cb612030e3ed8691e

But I'm not competent enough to judge t.


-- 
Tomasz TorczTo co nierealne -- tutaj jest normalne.
xmpp: zdzich...@chrome.pl  Ziomale na życie mają tu patenty specjalne.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Lennart Poettering]

On Tue, 11.07.17 16:55, Tomasz Torcz (to...@pipebreaker.pl) wrote:

> On Tue, Jul 11, 2017 at 04:10:38PM +0200, Lennart Poettering wrote:
> > On Tue, 11.07.17 16:07, Lennart Poettering (lenn...@poettering.net) wrote:
> > > Hmm, so I run a slightly older glibc, as I haven#t updated my system
> > > in a while:
> > > 
> > > $ strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
> > > % time seconds  usecs/call callserrors syscall
> > > -- --- --- - - 
> > >  25.950.001276   7   195   mmap
> > >  23.210.001141   7   16430 open
> > >  22.290.001096   9   119   munmap
> > >   6.530.000321   2   134   close
> > >   6.100.000300   2   135   fstat
> > >   5.150.000253   556   mprotect
> > >   4.880.000240   2   102   fstatfs
> > >   2.300.000113   432   read
> > > 
> > > getpid() is nowhere to be seen in this... Seems Fedora regressed on
> > > this too recently. Meh.
> > 
> > Forgot to mention:
> > 
> > $ rpm -qa glibc
> > glibc-2.24-4.fc25.x86_64
> > 
> > Apparently, this regressed between this version and
> > glibc-2.24-9.fc25.x86_64 hence.
> > 
> 
>   From glibc changelog:
> 
> * Wed Jun 07 2017 Arjun Shankar  - 2.24-6
> - Auto-sync with upstream release/2.24/master,
>   commit 7b60553e360731338631ccdda71590ac5deca137, fixing:
> - Remove the PID cache  (#1443976)

I commented on that bug now. It doesn#t really have a proper
explanation, all it says is that "The glibc PID cache negatively
interacts with setting up containers and namespaces."...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Timeout for 'Activating (start)' status

[Mikhail Kasimov]

11.07.2017 17:13, Lennart Poettering пишет:
> On Tue, 11.07.17 14:46, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:
>
>> Or, please, give a hint how service, which works in 'start -> do
>> something->exit' scheme (so this is oneshot type, as I understand:
>> https://www.freedesktop.org/software/systemd/man/systemd.service.html :
>> "Behavior of |oneshot| is similar to |simple|; however, it is expected
>> that the *process has to exit* before systemd starts follow-up units."),
>> be forced to be restarted on its failure.
> There's an RFE issue about adding Restart= for Type=oneshot too:
>
> https://github.com/systemd/systemd/issues/2582
>
> Would be happy to take patches that make that work...

Thanks for info!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Tomasz Torcz]

On Tue, Jul 11, 2017 at 04:10:38PM +0200, Lennart Poettering wrote:
> On Tue, 11.07.17 16:07, Lennart Poettering (lenn...@poettering.net) wrote:
> > Hmm, so I run a slightly older glibc, as I haven#t updated my system
> > in a while:
> > 
> > $ strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
> > % time seconds  usecs/call callserrors syscall
> > -- --- --- - - 
> >  25.950.001276   7   195   mmap
> >  23.210.001141   7   16430 open
> >  22.290.001096   9   119   munmap
> >   6.530.000321   2   134   close
> >   6.100.000300   2   135   fstat
> >   5.150.000253   556   mprotect
> >   4.880.000240   2   102   fstatfs
> >   2.300.000113   432   read
> > 
> > getpid() is nowhere to be seen in this... Seems Fedora regressed on
> > this too recently. Meh.
> 
> Forgot to mention:
> 
> $ rpm -qa glibc
> glibc-2.24-4.fc25.x86_64
> 
> Apparently, this regressed between this version and
> glibc-2.24-9.fc25.x86_64 hence.
> 

  From glibc changelog:

* Wed Jun 07 2017 Arjun Shankar  - 2.24-6
- Auto-sync with upstream release/2.24/master,
  commit 7b60553e360731338631ccdda71590ac5deca137, fixing:
- Remove the PID cache  (#1443976)

-- 
Tomasz TorczTo co nierealne -- tutaj jest normalne.
xmpp: zdzich...@chrome.pl  Ziomale na życie mają tu patenty specjalne.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Timeout for 'Activating (start)' status

[Lennart Poettering]

On Tue, 11.07.17 14:46, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:

> Or, please, give a hint how service, which works in 'start -> do
> something->exit' scheme (so this is oneshot type, as I understand:
> https://www.freedesktop.org/software/systemd/man/systemd.service.html :
> "Behavior of |oneshot| is similar to |simple|; however, it is expected
> that the *process has to exit* before systemd starts follow-up units."),
> be forced to be restarted on its failure.

There's an RFE issue about adding Restart= for Type=oneshot too:

https://github.com/systemd/systemd/issues/2582

Would be happy to take patches that make that work...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Lennart Poettering]

On Tue, 11.07.17 16:07, Lennart Poettering (lenn...@poettering.net) wrote:
> Hmm, so I run a slightly older glibc, as I haven#t updated my system
> in a while:
> 
> $ strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
> % time seconds  usecs/call callserrors syscall
> -- --- --- - - 
>  25.950.001276   7   195   mmap
>  23.210.001141   7   16430 open
>  22.290.001096   9   119   munmap
>   6.530.000321   2   134   close
>   6.100.000300   2   135   fstat
>   5.150.000253   556   mprotect
>   4.880.000240   2   102   fstatfs
>   2.300.000113   432   read
> 
> getpid() is nowhere to be seen in this... Seems Fedora regressed on
> this too recently. Meh.

Forgot to mention:

$ rpm -qa glibc
glibc-2.24-4.fc25.x86_64

Apparently, this regressed between this version and
glibc-2.24-9.fc25.x86_64 hence.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Lennart Poettering]

On Tue, 11.07.17 21:59, Michael Chapman (m...@very.puzzling.org) wrote:

> On Tue, 11 Jul 2017, Lennart Poettering wrote:
> > On Tue, 11.07.17 12:55, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > 
> > > On Tue, 2017-07-11 at 09:35 +0200, Lennart Poettering wrote:
> > > > Normally it's dead cheap to check that, it's just reading and
> > > > comparing one memory location. It's a pitty that this isn't the case
> > > > currently on Debian, but as it appears this is an oversight on their
> > > > side, and I am sure it will be eventually fixed there, if it hasn't
> > > > already.
> > > 
> > > Are you sure about those "Debian only" and "will be 'fixed'" parts? The
> > > Debian patch seems to be a cherry pick from upstream glibc. Is there
> > > evidence of some error that would cause effects only visible on Debian
> > > and nowhere else? And/or has the change been reverted or behavior
> > > otherwise modified upstream to limit the range of relevant versions?
> > 
> > See the links Vito provided:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909
> > https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d
> > 
> > i.e. Debian undid the PID caching to fix some issue that has been fix
> > properly now, and hence the PID caching should be turned on again.
> > 
> > On Fedora at least getpid() is not visible in strace, and is fully
> > cached, as it should be.
> 
> I just tested this on F25 and F26 beta, and it's certainly visible for me on
> both of them:
> 
>   # cat /etc/system-release
>   Fedora release 25 (Twenty Five)
>   # rpm -q glibc
>   glibc-2.24-9.fc25.x86_64
>   # strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
>   % time seconds  usecs/call callserrors syscall
>   -- --- --- - - 
>93.930.167020   2 83761   getpid
> 3.930.006983   2  3025   write
> 0.540.000953  1097   mmap
> 0.390.000696  1352 8 open
> 0.310.000558  1440   munmap
> 0.190.000332   842   mprotect
> 0.150.000264   645   fstat
> 0.140.000246   644   close

Hmm, so I run a slightly older glibc, as I haven#t updated my system
in a while:

$ strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 25.950.001276   7   195   mmap
 23.210.001141   7   16430 open
 22.290.001096   9   119   munmap
  6.530.000321   2   134   close
  6.100.000300   2   135   fstat
  5.150.000253   556   mprotect
  4.880.000240   2   102   fstatfs
  2.300.000113   432   read

getpid() is nowhere to be seen in this... Seems Fedora regressed on
this too recently. Meh.

Somebody should probably file a bug about this regression and get
clarification if this is going to remain slow, or if they are going to
fix that again... If this is going to remain slow, we shoud probably
find a different way to detect forks... we could install a
pthread_atfork() handler and set some flag...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 11, 2017 at 09:59:45PM +1000, Michael Chapman wrote:
> On Tue, 11 Jul 2017, Lennart Poettering wrote:
> >On Tue, 11.07.17 12:55, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> >
> >>On Tue, 2017-07-11 at 09:35 +0200, Lennart Poettering wrote:
> >>>Normally it's dead cheap to check that, it's just reading and
> >>>comparing one memory location. It's a pitty that this isn't the case
> >>>currently on Debian, but as it appears this is an oversight on their
> >>>side, and I am sure it will be eventually fixed there, if it hasn't
> >>>already.
> >>
> >>Are you sure about those "Debian only" and "will be 'fixed'" parts? The
> >>Debian patch seems to be a cherry pick from upstream glibc. Is there
> >>evidence of some error that would cause effects only visible on Debian
> >>and nowhere else? And/or has the change been reverted or behavior
> >>otherwise modified upstream to limit the range of relevant versions?
> >
> >See the links Vito provided:
> >
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909
> >https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d
> >
> >i.e. Debian undid the PID caching to fix some issue that has been fix
> >properly now, and hence the PID caching should be turned on again.
> >
> >On Fedora at least getpid() is not visible in strace, and is fully
> >cached, as it should be.
> 
> I just tested this on F25 and F26 beta, and it's certainly visible
> for me on both of them:
> 
>   # cat /etc/system-release
>   Fedora release 25 (Twenty Five)
>   # rpm -q glibc
>   glibc-2.24-9.fc25.x86_64
>   # strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
>   % time seconds  usecs/call callserrors syscall
>   -- --- --- - - 
>93.930.167020   2 83761   getpid
> 3.930.006983   2  3025   write
> 0.540.000953  1097   mmap
> 0.390.000696  1352 8 open
> 0.310.000558  1440   munmap
> 0.190.000332   842   mprotect
> 0.150.000264   645   fstat
> 0.140.000246   644   close
> 
>   # cat /etc/system-release
>   Fedora release 26 (Twenty Six)
>   # rpm -q glibc
>   glibc-2.25-7.fc26.x86_64
>   # strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
>   % time seconds  usecs/call callserrors syscall
>   -- --- --- - - 
>62.840.007874   4  2063   getpid
> 7.960.000998  1286   mmap
> 7.850.000983  2048 8 open
> 3.850.000483   954   mprotect
> 2.800.000351   571   write
> 2.750.000345  1132   read
> 2.690.000337   841   fstat
> 2.660.000333   840   close
> 
> The second machine had just been started, which is why the numbers
> are a lot lower. Nevertheless, getpid is still taking by far the
> most amount of time in syscalls.
> 
> Both of these are on Fedora's testing branch, but I don't think
> Fedora's regular branch has a significantly different version of
> glibc.

Yep, I can confirm that: many many getpid() syscalls on F26 and rawhide,
and none on F24.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Michael Chapman]

On Tue, 11 Jul 2017, Lennart Poettering wrote:

On Tue, 11.07.17 12:55, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:


On Tue, 2017-07-11 at 09:35 +0200, Lennart Poettering wrote:

Normally it's dead cheap to check that, it's just reading and
comparing one memory location. It's a pitty that this isn't the case
currently on Debian, but as it appears this is an oversight on their
side, and I am sure it will be eventually fixed there, if it hasn't
already.


Are you sure about those "Debian only" and "will be 'fixed'" parts? The
Debian patch seems to be a cherry pick from upstream glibc. Is there
evidence of some error that would cause effects only visible on Debian
and nowhere else? And/or has the change been reverted or behavior
otherwise modified upstream to limit the range of relevant versions?


See the links Vito provided:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d

i.e. Debian undid the PID caching to fix some issue that has been fix
properly now, and hence the PID caching should be turned on again.

On Fedora at least getpid() is not visible in strace, and is fully
cached, as it should be.


I just tested this on F25 and F26 beta, and it's certainly visible for me 
on both of them:


  # cat /etc/system-release
  Fedora release 25 (Twenty Five)
  # rpm -q glibc
  glibc-2.24-9.fc25.x86_64
  # strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
  % time seconds  usecs/call callserrors syscall
  -- --- --- - - 
   93.930.167020   2 83761   getpid
3.930.006983   2  3025   write
0.540.000953  1097   mmap
0.390.000696  1352 8 open
0.310.000558  1440   munmap
0.190.000332   842   mprotect
0.150.000264   645   fstat
0.140.000246   644   close

  # cat /etc/system-release
  Fedora release 26 (Twenty Six)
  # rpm -q glibc
  glibc-2.25-7.fc26.x86_64
  # strace -c journalctl --since -1hour 2>&1 >/dev/null | head -10
  % time seconds  usecs/call callserrors syscall
  -- --- --- - - 
   62.840.007874   4  2063   getpid
7.960.000998  1286   mmap
7.850.000983  2048 8 open
3.850.000483   954   mprotect
2.800.000351   571   write
2.750.000345  1132   read
2.690.000337   841   fstat
2.660.000333   840   close

The second machine had just been started, which is why the numbers are a 
lot lower. Nevertheless, getpid is still taking by far the most 
amount of time in syscalls.


Both of these are on Fedora's testing branch, but I don't think Fedora's 
regular branch has a significantly different version of glibc.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Timeout for 'Activating (start)' status

[Mikhail Kasimov]

Hello!


11.07.2017 13:49, Lennart Poettering пишет:
> On Thu, 06.07.17 16:43, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:
>
>> Hello!
>>
>> 've got an interesting trouble on timer-activated service -- 'systemctl
>> status' returns a log with 'Activating (start)' status:
>>
>> [1]
>> ==
>> k_mikhail@linux-mk500:~> systemctl status vba32update.service
>> ● vba32update.service - VBA32 Anti-Virus Update Service
>>Loaded: loaded (/etc/systemd/system/vba32update.service; disabled;
>> vendor preset: disabled)
>>Active: activating (start) since Чтв 2017-07-06 15:32:35 EEST; 35min ago
>>  Main PID: 6214 (vbaupdx)
>> Tasks: 1 (limit: 512)
>>CGroup: /system.slice/vba32update.service
>>└─6214 ./vbaupdx http://anti-virus.by/beta/update
>>
>> Июл 06 15:32:35 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update
>> Service...
>> Июл 06 15:32:35 linux-mk500 vbacl[6214]: Vba32 console scanner update
>> process started
>> Июл 06 15:32:35 linux-mk500 vbacl[6214]: Reading configuration options
>> from ./vbacl.ini
>> Июл 06 15:32:35 linux-mk500 vbacl[6214]: Using direct connection for update
>> k_mikhail@linux-mk500:~>
>> ==
>>
>>
>> Simultaneously:
>> [2]
>> ==
>> k_mikhail@linux-mk500:~> systemctl list-units -t timer
>> UNIT LOAD   ACTIVE SUB DESCRIPTION
>> vba32update.timerloaded active running Runs VBA32 Update Hourly
>> ==
>>
>> And that is normal. But 35 minutes for activating service is too long,
>> as for me.
> Well, process 6214 is still around as you can see above, and since you
> appear to have set Type=oneshot, that's really the right behaviour:
> the unit will be starting until process 6214 decides. if 35min is too
> long for that process, then this indicates that something is wrong in
> that process, and systemd is just the messenger.
>
> If you want to place a timeout on starting use TimeoutStartSec= and
> set it to whatever you like. If the timeout is then hit, systemd will
> abort the process and log about this and place the service in a failed
> state.

No problem at all. I 've modified vba32update.service by adding
TimeoutStarSec= and Restart=on-failure directives, because I wanna force
to restart service automatically if it gets 'failed' status.

[1]

k_mikhail@linux-mk500:~> cat vba32update.service
[Unit]

Description=VBA32 Anti-Virus Update Service
Requires=network.target
Wants=network-online.target
After=network.target network-online.target

[Service]
Type=oneshot
WorkingDirectory=/opt/vba/vbacl/
ExecStart=/opt/vba/vbacl/vbacl --update
EnvironmentFile=/opt/vba/vbacl/vbacl.ini
TimeoutStartSec=120s
Restart=on-failure

[Install]
WantedBy=multi-user.target



Then attempt to vba32update.service:

k_mikhail@linux-mk500:~> systemctl status -l vba32update.service
● vba32update.service - VBA32 Anti-Virus Update Service
   Loaded: error (Reason: Invalid argument)
   Active: activating (start) since Вто 2017-07-11 02:48:54 EEST; 11h ago
 Main PID: 22712 (vbaupdx)
   CGroup: /system.slice/vba32update.service
   └─22712 ./vbaupdx http://anti-virus.by/beta/update

Июл 11 02:48:54 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update
Service...
Июл 11 02:48:54 linux-mk500 vbacl[22712]: Vba32 console scanner update
process started
Июл 11 02:48:54 linux-mk500 vbacl[22712]: Reading configuration options
from ./vbacl.ini
Июл 11 02:48:54 linux-mk500 vbacl[22712]: Using direct connection for update
Июл 11 14:22:19 linux-mk500 systemd[1]: vba32update.service: Service has
Restart= setting other than no, which isn't allowed for Type=oneshot
services. Refusing.


Brilliant. Let's go to man-page
https://www.freedesktop.org/software/systemd/man/systemd.service.html on
Restart= directive text and we can see _no_ _info_ about such
restriction. Lack-of-info on documentaion.

Or, please, give a hint how service, which works in 'start -> do
something->exit' scheme (so this is oneshot type, as I understand:
https://www.freedesktop.org/software/systemd/man/systemd.service.html :
"Behavior of |oneshot| is similar to |simple|; however, it is expected
that the *process has to exit* before systemd starts follow-up units."),
be forced to be restarted on its failure.
>
> But systemd is not a magic wand that can make hanging processes
> suddenly work...

I understand it. I just try to find the way how to resolve my usecase
problem by options, which systemd provides.

Thanks!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Timeout for 'Activating (start)' status

[Lennart Poettering]

On Thu, 06.07.17 16:43, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:

> Hello!
> 
> 've got an interesting trouble on timer-activated service -- 'systemctl
> status' returns a log with 'Activating (start)' status:
> 
> [1]
> ==
> k_mikhail@linux-mk500:~> systemctl status vba32update.service
> ● vba32update.service - VBA32 Anti-Virus Update Service
>Loaded: loaded (/etc/systemd/system/vba32update.service; disabled;
> vendor preset: disabled)
>Active: activating (start) since Чтв 2017-07-06 15:32:35 EEST; 35min ago
>  Main PID: 6214 (vbaupdx)
> Tasks: 1 (limit: 512)
>CGroup: /system.slice/vba32update.service
>└─6214 ./vbaupdx http://anti-virus.by/beta/update
> 
> Июл 06 15:32:35 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update
> Service...
> Июл 06 15:32:35 linux-mk500 vbacl[6214]: Vba32 console scanner update
> process started
> Июл 06 15:32:35 linux-mk500 vbacl[6214]: Reading configuration options
> from ./vbacl.ini
> Июл 06 15:32:35 linux-mk500 vbacl[6214]: Using direct connection for update
> k_mikhail@linux-mk500:~>
> ==
> 
> 
> Simultaneously:
> [2]
> ==
> k_mikhail@linux-mk500:~> systemctl list-units -t timer
> UNIT LOAD   ACTIVE SUB DESCRIPTION
> vba32update.timerloaded active running Runs VBA32 Update Hourly
> ==
> 
> And that is normal. But 35 minutes for activating service is too long,
> as for me.

Well, process 6214 is still around as you can see above, and since you
appear to have set Type=oneshot, that's really the right behaviour:
the unit will be starting until process 6214 decides. if 35min is too
long for that process, then this indicates that something is wrong in
that process, and systemd is just the messenger.

If you want to place a timeout on starting use TimeoutStartSec= and
set it to whatever you like. If the timeout is then hit, systemd will
abort the process and log about this and place the service in a failed
state.

But systemd is not a magic wand that can make hanging processes
suddenly work...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Jan Synacek]

On Mon, Jul 10, 2017 at 4:41 PM, Lennart Poettering
 wrote:
> On Mon, 10.07.17 15:58, Lennart Poettering (lenn...@poettering.net) wrote:
>
>> On Mon, 10.07.17 15:16, Jan Synacek (jsyna...@redhat.com) wrote:
>>
>> > On Mon, Jul 10, 2017 at 12:42 PM, Lennart Poettering
>> >  wrote:
>> > > Now, because this is so weakly defined, we hence do not follow POSIX
>> > > rules, but filter out more that might be dangerous. Specifically:
>> > >
>> > > 1. We do not permit empty usernames
>> > > 2. We don't permit the first character to be numeric
>> > >(This also filters out fully numeric user names)
>> > > 3. We do not permit dots in usernames, neither at the beginning nor in
>> > >the middle.
>> > > 4. We do not permit "-" at the beginning of usernames (something which
>> > >POSIX explicitly suggests, btw)
>> > > 5. We require that the user name fits in the utmp user name field, so
>> > >that we can always log properly about it.
>> >
>> > Is this documented somewhere? If not, it would be great to have it
>> > documented. I'm pretty sure that this exact paragraph would be ok.
>>
>> There's a longer (and not entirely complete) comment about this in the
>> sources, but other than that it's not explicitly documented.
>>
>> If you prep a patch that adds this to the User=/Group= man page, this
>> would certainly be welcome. However, it should be reworded, as we
>> shouldn't say "We" there, and probably drop explicit references to
>> POSIX and utmp there, and instead just dryly state the accepted
>> character set + minimum and maximum string lengths.
>
> I have posted a PR documenting this just now:
>
> https://github.com/systemd/systemd/pull/6321

Thanks for the fast response!

-- 
Jan Synacek
Software Engineer, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Uoti Urpala]

Resend with correct list address
On Tue, 2017-07-11 at 12:00 +0200, Lennart Poettering wrote:
> On Tue, 11.07.17 12:55, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > Are you sure about those "Debian only" and "will be 'fixed'" parts? The
> > Debian patch seems to be a cherry pick from upstream glibc. Is there
> > evidence of some error that would cause effects only visible on Debian
> > and nowhere else? And/or has the change been reverted or behavior
> > otherwise modified upstream to limit the range of relevant versions?
> 
> See the links Vito provided:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d
> 
> i.e. Debian undid the PID caching to fix some issue that has been fix
> properly now, and hence the PID caching should be turned on again.

That seems backwards: the commit cherry-picked by Debian seems to be
c579f48edba88380635a, which is NEWER than above 0cb313f7cb0e418b3d56.
In other words, it seems 0cb313 was a failed attempt at a fix and the
patch cherry-picked by Debian was needed to properly fix things.

> On Fedora at least getpid() is not visible in strace, and is fully
> cached, as it should be.

Is that glibc 2.25? It seems to contain c579f48 at least; could be a
Fedora-specific change though?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Uoti Urpala]

On Tue, 2017-07-11 at 09:35 +0200, Lennart Poettering wrote:
> Normally it's dead cheap to check that, it's just reading and
> comparing one memory location. It's a pitty that this isn't the case
> currently on Debian, but as it appears this is an oversight on their
> side, and I am sure it will be eventually fixed there, if it hasn't
> already.

Are you sure about those "Debian only" and "will be 'fixed'" parts? The
Debian patch seems to be a cherry pick from upstream glibc. Is there
evidence of some error that would cause effects only visible on Debian
and nowhere else? And/or has the change been reverted or behavior
otherwise modified upstream to limit the range of relevant versions?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Lennart Poettering]

On Tue, 11.07.17 12:55, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> On Tue, 2017-07-11 at 09:35 +0200, Lennart Poettering wrote:
> > Normally it's dead cheap to check that, it's just reading and
> > comparing one memory location. It's a pitty that this isn't the case
> > currently on Debian, but as it appears this is an oversight on their
> > side, and I am sure it will be eventually fixed there, if it hasn't
> > already.
> 
> Are you sure about those "Debian only" and "will be 'fixed'" parts? The
> Debian patch seems to be a cherry pick from upstream glibc. Is there
> evidence of some error that would cause effects only visible on Debian
> and nowhere else? And/or has the change been reverted or behavior
> otherwise modified upstream to limit the range of relevant versions?

See the links Vito provided:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d

i.e. Debian undid the PID caching to fix some issue that has been fix
properly now, and hence the PID caching should be turned on again.

On Fedora at least getpid() is not visible in strace, and is fully
cached, as it should be.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Lennart Poettering]

On Mon, 10.07.17 22:23, Ian Pilcher (arequip...@gmail.com) wrote:

> I'm playing using systemd-networkd (rather than the legacy network
> service) on my Banana Pi CentOS 7 firewall.  (See the "Bouncing
> interface once chrony is synced" thread for background.)
> 
> I have "DHCP=yes" in the [Network] section of my WAN interface
> (eth0.256.network):
> 
>  [Match]
>  Name=eth0.256
> 
>  [Network]
>  DHCP=yes
>  IPForward=yes
>  #IPv6AcceptRA=yes - Not supported in v219
> 
>  [DHCP]
>  UseHostname=no
> 
> For some reason, though, only the IPv4 DHCP request is being sent.  I
> have verified with tcpdump that no "dhcp6 solicit" packets are ever
> sent.

Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Lennart Poettering]

On Mon, 10.07.17 14:04, vcap...@pengaru.com (vcap...@pengaru.com) wrote:

> > > Except there's always a risk of these things regressing to normal 
> > > syscalls,
> > > and one has to weigh the utility against that.  It's unclear to me what
> > > significant utility having the sd-journal API police changing pids by
> > > calling getpid() at every public entrypoint is bringing to the table.
> > 
> > So it seems the issue has been fixed in glibc upstream more than a year
> > ago, and it doesn't seem to make sense to optimize current systemd git for
> > that.
> > 
> 
> Can you provide a commit id?  I took a glance at 
> sourcewaire.org/git/gitweb.cgi
> for getpid commits and didn't see anything relevant since the removal[1].
> 
> 
> > I see the argument that the getpid() checks are a bit excessive. Is their
> > overhead actually noticeable with current glibc?
> > 
> 
> On my spare arch system I still see gratuitous getpid() calls from
> journalctl, which is on glibc 2.5-2.
> 
> The pollution of strace output alone due to these checks is nuisance enough
> for me to want the checks removed, considering their only value is to catch
> programmer errors.  There's an abundance of potential programmer errors
> we're not making any effort to prevent, why is this one so privileged that
> it warrants policing?

strace doesn't show getpid() calls if they are properly cached. While
stracing journalctl I never have seen a single one of them...

> I appreciate Lennart's point about the hazards of forking from threaded
> programs.  It just doesn't seem like a valid rationalization for sprinkling
> a system library's entrypoints with getpid() calls to catch this in
> production.

Normally it's dead cheap to check that, it's just reading and
comparing one memory location. It's a pitty that this isn't the case
currently on Debian, but as it appears this is an oversight on their
side, and I am sure it will be eventually fixed there, if it hasn't already.

> Considering the associated potential costs, and the historic controversy
> surrounding the caching of this particular syscall[2] I'm a bit confused by
> the status quo.

Well, normally there's next to no cost to this, on pretty much any non-Debian
distro there isn't any price for this to pay...

I mean, we could certainly cache that value in our code too, but given
that glibc does that already in the normal case I think this is better
left to be fixed in glibc rather than our code.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Mantas Mikulėnas]

On Tue, Jul 11, 2017 at 6:23 AM, Ian Pilcher  wrote:

> I'm playing using systemd-networkd (rather than the legacy network
> service) on my Banana Pi CentOS 7 firewall.  (See the "Bouncing
> interface once chrony is synced" thread for background.)
>
> […]
>
> For some reason, though, only the IPv4 DHCP request is being sent.  I
> have verified with tcpdump that no "dhcp6 solicit" packets are ever
> sent.
>
> I also have a 32-bit ARM VM (qemu) running CentOS 7.  It does not
> exhibit this behavior; i.e. systemd-networkd does send dhcp6 solicit
> packets from this VM.  The most significant difference between the VM
> and the firewall is that the firewall has an extremely minimal set of
> packages installed.
>

Do both systems receive router advertisements? Standard DHCPv6 is only
triggered by RAs with the "managed" flags set. (I vaguely recall RFEs for
forced DHCPv6, as some ISPs don't bother with RA on the WAN side, but I'm
not sure if that was implemented. Even if it were, DHCPv6 doesn't carry
"default gateway" information...)

Is there some library or package that is required for DHCP v6 to work
> (something that might have slipped by an RPM packager)?
>

All networking code is in-tree, including the DHCP and RA processing.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel