Bug#822635: udev rules for USB device access effective at boot, but not on hotplug
On Fri, Mar 23, 2018 at 05:17:11PM +0100, Michael Biebl wrote: > On Mon, 22 Jan 2018 18:10:58 +0100 Michael Biebl > wrote: > > Hi Josh! > > > > On Wed, 21 Dec 2016 20:15:12 +0100 Michael Biebl wrote: > > > On Fri, 6 May 2016 18:12:27 -0500 Martin Pitt wrote: > > > > Control: tag -1 moreinfo > > > > > > > > Hello Josh, > > > > > > > > Josh Triplett [2016-04-25 13:48 -0700]: > > > > > ~$ cat /etc/udev/rules.d/99-local-gnubby.rules > > > > > SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0200", > > > > > TAG+="uaccess" > > > > > > > > > > If I boot with the device attached, this seems to take effect: > > > > > > > > > > However, if I unplug and replug the device, this rule no longer seems > > > > > to take > > > > > effect: > > > > > > > > The uaccess tag is evaluated in /lib/udev/rules.d/73-seat-late.rules, > > > > thus 99-* is too late. Can you please move it to e. g. > > > > 70-gnubby.rules? I'm fairly sure it will work then, but I'll keep the > > > > bug open until you confirm, just in case. > > > > > > > > > > The dump from Josh shows, that the uaccess udev property is properly > > > set. So I don't think it's an udev rules ordering issue. > > > > > > I think the problem rather is, that you are already logged in and the > > > ACLs are only applied on login or when the session becomes active. > > > > > > I assume if you log out and re-login after the hotplug, the ACL is > > > properly applied? > > > > Any updates on this bug report? Is there still something which needs to > > be addressed on the systemd side? If so we need to further investigate > > the issue. > > Josh, any updates on this? I'm not currently using the device, so I don't know the status of this issue. Regarding the mention of when the ACLs are applied, though, is that true in general? I thought that if you hotplugged a device that the user is supposed to have access to, they'd immediately get access to it. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#875557: Info received (Bug#875557: systemd: service mark as enabled but not in reality)
hm, the email address bounces here: > >The mail system > > : host mx.cblue.be[193.104.37.23] said: 550 Unrouteable > address (in reply to RCPT TO command) > > > > Reporting-MTA: dns; dd17218.kasserver.com > X-Postfix-Queue-ID: A90216801856 > X-Postfix-Sender: rfc822; bi...@debian.org > Arrival-Date: Fri, 23 Mar 2018 17:12:34 +0100 (CET) > > Final-Recipient: rfc822; sth...@cblue.be > Original-Recipient: rfc822;sth...@cblue.be > Action: failed > Status: 5.0.0 > Remote-MTA: dns; mx.cblue.be > Diagnostic-Code: smtp; 550 Unrouteable address > -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#831414: marked as done (systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface)
Your message dated Fri, 23 Mar 2018 17:24:02 +0100 with message-id and subject line Re: Bug#831414: systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface has caused the Debian Bug report #831414, regarding systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 831414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831414 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 230-5pitti1 Severity: minor Tags: ipv6 Hi, I am filing this as severity minor because this bug is in a version that is not officially in Debian. I am filing it nevertheless because systemd with this IPv6 user space code active should not be in Debian. If this were an official version, this would be an important bug, with the potential for "serious" at maintainer discretion. While following up Martin's requests for #815793 and #815884, I have found new misbehsvior regarding IPv6. Given a host that also acts as a router, with the following network setup: 2: eth0: mtu 1500 qdisc pfifo_fast state UP link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0 valid_lft 12650sec preferred_lft 12650sec inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86309sec preferred_lft 14309sec inet6 2001:db8:0:3282::1d:250/128 scope global valid_lft forever preferred_lft forever inet6 2001:db8:0:3282::1d:100/64 scope global valid_lft forever preferred_lft forever inet6 fe80::5604:a6ff:fe82:2100/64 scope link valid_lft forever preferred_lft forever 3: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether c6:f4:98:dc:5e:21 brd ff:ff:ff:ff:ff:ff inet 192.168.29.254/24 brd 192.168.29.255 scope global br0 valid_lft forever preferred_lft forever inet6 2001:db8:0:328d::1d:153/64 scope global valid_lft forever preferred_lft forever inet6 2001:db8:0:328d::1d:100/64 scope global valid_lft forever preferred_lft forever inet6 fec0:0:0:::3/128 scope site valid_lft forever preferred_lft forever inet6 fec0:0:0:::2/128 scope site valid_lft forever preferred_lft forever inet6 fec0:0:0:::1/128 scope site valid_lft forever preferred_lft forever inet6 fe80::c4f4:98ff:fedc:5e21/64 scope link valid_lft forever preferred_lft forever On br0, there is a radvd, advertising a prefix on br0: interface br0 { AdvSendAdvert on; MinRtrAdvInterval 600; MaxRtrAdvInterval 1200; prefix 2001:db8:0:328d::/64 { DeprecatePrefix on; }; RDNSS 2001:db8:0:328d::1d:153 { AdvRDNSSLifetime 1200; }; }; When the radvd is started, the local host seems to learn the prefix from the locally running radvd and _configures_ _it_ _on_ _eth0_, which is plain wrong: 2: eth0: mtu 1500 qdisc pfifo_fast state UP gr oup default qlen 1000 link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0 valid_lft 12530sec preferred_lft 12530sec inet6 2001:db8:0:328d:5604:a6ff:fe82:2100/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86390sec preferred_lft 14390sec inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86189sec preferred_lft 14189sec inet6 2001:db8:0:3282::1d:250/128 scope global valid_lft forever preferred_lft forever inet6 2001:db8:0:3282::1d:100/64 scope global valid_lft forever preferred_lft forever inet6 fe80::5604:a6ff:fe82:2100/64 scope link valid_lft forever preferred_lft forever It also learns a default route pointing to its own link local IP address on br0: [2/502]mh@fan:~$ ip -6 r 2001:db8:0:3282::1d:250 dev eth0 proto kernel metric 256 pref medium 2001:db8:0:3282::/64 dev eth0 proto kernel metric 256 pref medium 2001:db8:0:3282::/64 dev eth0 proto ra metric 1024 pref medium 2001:db8:0:328d::/64 dev br0 proto kernel metric 256 pref medium 2001:db8:0:328d::/64 dev eth0 proto ra metric 1024 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev dummy0
Bug#822635: udev rules for USB device access effective at boot, but not on hotplug
On Mon, 22 Jan 2018 18:10:58 +0100 Michael Biebl wrote: > Hi Josh! > > On Wed, 21 Dec 2016 20:15:12 +0100 Michael Biebl wrote: > > On Fri, 6 May 2016 18:12:27 -0500 Martin Pitt wrote: > > > Control: tag -1 moreinfo > > > > > > Hello Josh, > > > > > > Josh Triplett [2016-04-25 13:48 -0700]: > > > > ~$ cat /etc/udev/rules.d/99-local-gnubby.rules > > > > SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0200", > > > > TAG+="uaccess" > > > > > > > > If I boot with the device attached, this seems to take effect: > > > > > > > > However, if I unplug and replug the device, this rule no longer seems > > > > to take > > > > effect: > > > > > > The uaccess tag is evaluated in /lib/udev/rules.d/73-seat-late.rules, > > > thus 99-* is too late. Can you please move it to e. g. > > > 70-gnubby.rules? I'm fairly sure it will work then, but I'll keep the > > > bug open until you confirm, just in case. > > > > > > > The dump from Josh shows, that the uaccess udev property is properly > > set. So I don't think it's an udev rules ordering issue. > > > > I think the problem rather is, that you are already logged in and the > > ACLs are only applied on login or when the session becomes active. > > > > I assume if you log out and re-login after the hotplug, the ACL is > > properly applied? > > Any updates on this bug report? Is there still something which needs to > be addressed on the systemd side? If so we need to further investigate > the issue. Josh, any updates on this? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#875557: systemd: service mark as enabled but not in reality
Control: tags -1 + moreinfo On Tue, 12 Sep 2017 10:08:49 +0200 Michael Biebl wrote: > Am 12.09.2017 um 09:45 schrieb sthiry: > > Package: systemd > > Version: 232-25+deb9u1 > > Severity: normal > > > > Hello, > > > > I use multiple php-fpm process to run apache websites and I have to create > > one process by site, so I have a service file named php7-fpm@.service. It > > let me create service like this php7-fpm@mysite that > > I have to enable once it is created. So I notice that when I enable one > > service, the others are mark as enabled when I type "service php7-fpm* > > status", but they are not enabled. So you have to enable all > > services. > > Can you please include the full service file you are using and the > output of the commands. Would be great, if you can provide the requested information. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#875557: systemd: service mark as enabled but not in reality
Processing control commands: > tags -1 + moreinfo Bug #875557 [systemd] systemd: service mark as enabled but not in reality Added tag(s) moreinfo. -- 875557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875557 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: bug 868159 is forwarded to https://github.com/systemd/systemd/issues/8566
Processing commands for cont...@bugs.debian.org: > forwarded 868159 https://github.com/systemd/systemd/issues/8566 Bug #868159 [systemd] systemd-setup-tmpfiles startup error when /srv is on read-only fs Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/8566'. > thanks Stopping processing here. Please contact me if you need assistance. -- 868159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868159 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#863710: marked as done (journald's most recent entries)
Your message dated Fri, 23 Mar 2018 17:03:19 +0100 with message-id <917a9097-0c17-577d-d435-f4154b9fc...@debian.org> and subject line Re: Bug#863710: journald's most recent entries has caused the Debian Bug report #863710, regarding journald's most recent entries to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 863710: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863710 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 215-17+deb8u6 Severity: normal Dear Maintainer, I have tried to retrieve recent journal entries (with matching fields), but the retrieved entries were not the most recent ones: $ journalctl OBJECT_ID=50483 -n 15 | tail -n 1 | cut -c 1-15 May 29 23:05:13 $ journalctl OBJECT_ID=50483 -n 14 | tail -n 1 | cut -c 1-15 May 29 23:05:13 $ journalctl OBJECT_ID=50483 -n 13 | tail -n 1 | cut -c 1-15 May 30 03:04:57 $ journalctl OBJECT_ID=50483 -n 12 | tail -n 1 | cut -c 1-15 May 30 07:05:03 $ journalctl OBJECT_ID=50483 -n 11 | tail -n 1 | cut -c 1-15 May 30 07:05:03 $ journalctl OBJECT_ID=50483 -n 12 | tail -n 1 | cut -c 1-15 May 30 07:05:03 $ journalctl OBJECT_ID=50483 -n 13 | tail -n 1 | cut -c 1-15 May 30 03:04:57 $ journalctl OBJECT_ID=50483 -n 14 | tail -n 1 | cut -c 1-15 May 29 23:05:13 $ journalctl OBJECT_ID=50483 -n 15 | tail -n 1 | cut -c 1-15 May 29 23:05:13 Here is another example, a bit redacted (any is identical to another : the same few messages get inserted there roughly every 4 hours): $ journalctl OBJECT_ID=50482 -n 1 -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:13 MSK. -- May 30 07:03:49 mars mmdb[131728]: $ journalctl OBJECT_ID=50482 -n 2 -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:14 MSK. -- May 30 03:04:11 mars mmdb[131728]: May 30 03:04:11 mars mmsocks[946]: $ journalctl OBJECT_ID=50482 -n 3 -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:22 MSK. -- May 29 23:04:18 mars mmdb[131728]: May 29 23:04:19 mars mmsocks[946]: May 29 23:05:19 mars rtms4[35053]: $ journalctl OBJECT_ID=50482 -n 4 -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:26 MSK. -- May 29 19:06:03 mars mmdb[131728]: May 29 19:06:03 mars mmsocks[946]: May 29 19:07:03 mars rtms4[27816]: May 29 19:07:03 mars mmsocks[946]: Repeating the same commands led to same results, as in the first example. After that, new messages were inserted, and it got shifted: $ journalctl OBJECT_ID=50482 -n 1 -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:20:31 MSK. -- May 30 11:10:06 mars mmdb[131728]: $ journalctl OBJECT_ID=50482 -n 2 -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:21:14 MSK. -- May 30 07:03:49 mars mmdb[131728]: May 30 07:03:51 mars mmsocks[946]: It doesn't seem to happen with OBJECT_ID's where the messages are not as repetitive. And it works fine if the `-n` option is not specified, or if its argument is greater than the amount of messages for a given OBJECT_ID. Looks like a similar behaviour can be reproduced using systemd units and shell scripts (just printing the same messages), with no custom fields or programs, but I wasn't able to get a clean example (got a few attempts mixed together the only time when it worked that way, and then it got fixed on its own -- unlike the above examples). The default /etc/systemd/journald.conf was used. -- Package-specific info: -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-59 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-6 ii libc6 2.19-18+deb8u7 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2+deb8u2 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1+deb8u2 ii libselinux1 2.3-2 ii libsystemd0 215-17+deb8u6 ii mount 2.25.2-6 ii sysv-rc 2.88dsf-59 ii udev215-17+deb8u6 ii util-linux 2.25.2-6 Versions of packages systemd recommends: ii dbus1.8.22-0+deb8u1 pn libpam-systemd Versions of packages systemd s
Bug#803524: journalctl too slow
Control: tags -1 + moreinfo On Sat, 31 Oct 2015 01:46:59 +0100 Christoph Egger wrote: > Package: systemd > Version: 215-17+deb8u2 > Severity: normal > File: /bin/journalctl > > Hi! > > `journalctl -u nsd.service` just takes 10 minutes (!) cpu time to > scrol to the newest entries. I'd call that too much for something > that's supposed to replace a `grep nsd /var/log/syslog` Is this still reproducible with a recent version of systemd? Is this with persistent journal enabled? If so, - how big is /var/log/journal? - does journalctl --verify report any errors? - is the problem reproducible after removing existing journal files? Fwiw, if you are interested in the newest journal entries, journalctl now provides a -r switch, ie. it shows the newest entries first. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: journalctl too slow
Processing control commands: > tags -1 + moreinfo Bug #803524 [systemd] journalctl too slow Added tag(s) moreinfo. -- 803524: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803524 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#892585: systemd: can not create user.slice/user session, after upgrade systemd from 237-4 to 238-1/2
On Wed, 21 Mar 2018 16:16:40 +0800 johnw wrote: > After upgrade systemd to 238-3, I still have this problem :( > Any one? > Help, please. Does it work if you switch to a different display manager, like say lightdm (which IIRC is the preferred one of xfce). Might be a problem specific to slim, since I don't see any such issues myself here (using GNOME/gdm). Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]
On 23/03/18 14:25, Mathieu Malaterre wrote: > Hi James, > > On Fri, Mar 23, 2018 at 3:19 PM, James Cowgill wrote: >> Control: notforwarded -1 >> >> Hi, >> >> On 22/03/18 14:28, Michael Biebl wrote: >>> Am 22.03.2018 um 12:31 schrieb James Cowgill: I sent a patch upstream (see above). >>> >>> Thanks! >> >> Unfortunately I've had to ask for this to be reverted: >> https://github.com/systemd/systemd/pull/8563 > > Are you saying that none of the unit tests failed after your changes ? > that's kindda scary :( No nothing failed. James signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]
Hi James, On Fri, Mar 23, 2018 at 3:19 PM, James Cowgill wrote: > Control: notforwarded -1 > > Hi, > > On 22/03/18 14:28, Michael Biebl wrote: >> Am 22.03.2018 um 12:31 schrieb James Cowgill: >>> I sent a patch upstream (see above). >> >> Thanks! > > Unfortunately I've had to ask for this to be reverted: > https://github.com/systemd/systemd/pull/8563 Are you saying that none of the unit tests failed after your changes ? that's kindda scary :( > It turns out that enabling MemoryDenyWriteExecute on MIPS causes any > applications which use threads to fail because the MIPS toolchain > (still) does not implement PT_GNU_STACK. So this bug is going to require > some extra toolchain support (at least glibc and one of gcc/binutils but > I can't remember which) to fix. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]
Processing control commands: > notforwarded -1 Bug #893605 [src:systemd] warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp] Unset Bug forwarded-to-address -- 893605: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893605 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]
Control: notforwarded -1 Hi, On 22/03/18 14:28, Michael Biebl wrote: > Am 22.03.2018 um 12:31 schrieb James Cowgill: >> I sent a patch upstream (see above). > > Thanks! Unfortunately I've had to ask for this to be reverted: https://github.com/systemd/systemd/pull/8563 It turns out that enabling MemoryDenyWriteExecute on MIPS causes any applications which use threads to fail because the MIPS toolchain (still) does not implement PT_GNU_STACK. So this bug is going to require some extra toolchain support (at least glibc and one of gcc/binutils but I can't remember which) to fix. James signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Bug #892794 in systemd marked as pending
Processing control commands: > tag -1 pending Bug #892794 [systemd] systemd-networkd fails to configure IPv6 without MTU from RA Bug #892651 [systemd] networkd: no IPv6 default route after point release Added tag(s) pending. Added tag(s) pending. -- 892651: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892651 892794: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892794 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#893866: stretch-pu: package systemd/232-25+deb9u3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi, we already briefly discussed this via IRC on #debian-release. The last stable upload of systemd introduced a rather nasty regression in networkd, which broke IPv6 support for lots of users. KiBi was so kind to dig out the relevant upstream commit which fixes this and got confirmation from the bug reporter(s) that with this patch applied, networkd behaves properly. I thus would like to get this update into stable as quickly as possible. Here's the changelog, debdiff is attached: systemd (232-25+deb9u3) stretch; urgency=medium [ Cyril Brulebois ] * networkd-ndisc: Handle missing mtu gracefully. The previous upload made networkd respect the MTU field in IPv6 RA but unfortunately broke setups where there's no such field. (Closes: #892794) -- Michael Biebl Fri, 23 Mar 2018 13:55:43 +0100 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff --git a/debian/changelog b/debian/changelog index e7b7ff1..1117655 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +systemd (232-25+deb9u3) stretch; urgency=medium + + [ Cyril Brulebois ] + * networkd-ndisc: Handle missing mtu gracefully. +The previous upload made networkd respect the MTU field in IPv6 RA but +unfortunately broke setups where there's no such field. (Closes: #892794) + + -- Michael Biebl Fri, 23 Mar 2018 13:55:43 +0100 + systemd (232-25+deb9u2) stretch; urgency=medium * networkd: Handle MTU field in IPv6 RA (Closes: #878162) diff --git a/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch b/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch new file mode 100644 index 000..59d6808 --- /dev/null +++ b/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch @@ -0,0 +1,28 @@ +From: =?utf-8?q?J=C3=B6rg_Thalheim?= +Date: Mon, 19 Dec 2016 15:34:07 +0100 +Subject: networkd-ndisc: handle missing mtu gracefully (#4913) + +At least bird's implementation of router advertisement does not +set MTU option by default (instead it supplies an option to the user). +In this case just leave MTU as it is. + +(cherry picked from commit 29b5ad083a6925efec8e188013d1298742e0baaa) +--- + src/network/networkd-ndisc.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/src/network/networkd-ndisc.c b/src/network/networkd-ndisc.c +index 9cfdf01..d3fa56b 100644 +--- a/src/network/networkd-ndisc.c b/src/network/networkd-ndisc.c +@@ -117,7 +117,9 @@ static void ndisc_router_process_default(Link *link, sd_ndisc_router *rt) { + } + + r = sd_ndisc_router_get_mtu(rt, &mtu); +-if (r < 0) { ++if (r == -ENODATA) ++mtu = 0; ++else if (r < 0) { + log_link_warning_errno(link, r, "Failed to get default router MTU from RA: %m"); + return; + } diff --git a/debian/patches/series b/debian/patches/series index 3f93454..2866963 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -78,6 +78,7 @@ networkd-handle-MTU-field-in-IPv6-RA-4719.patch shared-Add-a-linker-script-so-that-all-functions-are-tagg.patch resolved-fix-loop-on-packets-with-pseudo-dns-types.patch machinectl-don-t-output-No-machines.-with-no-legend-optio.patch +networkd-ndisc-handle-missing-mtu-gracefully-4913.patch debian/Use-Debian-specific-config-files.patch debian/don-t-try-to-start-autovt-units-when-not-running-wit.patch debian/Make-logind-hostnamed-localed-timedated-D-Bus-activa.patch ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#883569: libpam-systemd: Prefer systemd-sysv over systemd-shim
Hello Michael, Michael Biebl [2018-03-19 6:44 +0100]: > So, what are we going to do now then? "Nothing" I supppose. I don't think it's actually broken right now, it just feels a little odd to prefer SysV in the dependencies. But with systemd being installed by default, I suppose it's okay. Martin signature.asc Description: PGP signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers