[Touch-packages] [Bug 1811295] Re: systemctl daemon-reexec does not update group membership
I encountered this same issue on Ubuntu 22.04.03 LTS (systemd 249.11-0ubuntu3.11). After `usermod -a -G `, processes that are spawned or restarted by systemd user service units do not pick up the new group (`grep Group /proc//status` does not include the new group) until after the `systemd --user` process is killed using `sudo loginctl terminate-user ` (which logs the user out) or `sudo systemctl restart user@.service` (which doesn't log the user out but effectively breaks the user's session) or something similar. Neither `systemctl --user daemon-reload` nor `systemctl --user daemon-reexec` helps. There doesn't appear to be any non-disruptive way to pick up the group change. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1811295 Title: systemctl daemon-reexec does not update group membership Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 16.04.4 LTS using Package: systemd Architecture: amd64 Version: 229-4ubuntu21.10 Changes the group membership are not picked up by the systemd process for a logged-in user or for a user with enable-linger set regardless of login status. Evidently the systemctl --user daemon-reexec command preserves group membership across the daemon restart. This is bad. It means that only a reboot or sudo loginctl terminate-user will update the group membership to the proper set. Both of those things are extreme disruptions for a system/user that runs servers. Can systemctl daemon-reexec be made to update group membership for the user in the systemd process? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811295/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1811295] Re: systemctl daemon-reexec does not update group membership
** Changed in: systemd (Ubuntu) Status: Invalid => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1811295 Title: systemctl daemon-reexec does not update group membership Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 16.04.4 LTS using Package: systemd Architecture: amd64 Version: 229-4ubuntu21.10 Changes the group membership are not picked up by the systemd process for a logged-in user or for a user with enable-linger set regardless of login status. Evidently the systemctl --user daemon-reexec command preserves group membership across the daemon restart. This is bad. It means that only a reboot or sudo loginctl terminate-user will update the group membership to the proper set. Both of those things are extreme disruptions for a system/user that runs servers. Can systemctl daemon-reexec be made to update group membership for the user in the systemd process? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811295/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1868780] Re: [virtio] Xubuntu 20.04 - Blank screen after login
The problem is that Xfwm's built-in compositor and virgl don't play nice together. Work-around: Boot the VM with virgl=off (on the video device) or gl=off (on the display), run xfwm4-tweaks-settings in the VM, select the "Compositor" tab, and uncheck "Enable display compositing". Then shut down the VM and re-enable virgl. picom works with Xfwm and doesn't seem to have the same issues, so if you want a compositor, install/use picom instead of using Xfwm's built- in compositor: https://wiki.archlinux.org/index.php/Picom -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1868780 Title: [virtio] Xubuntu 20.04 - Blank screen after login Status in lightdm package in Ubuntu: New Bug description: Both on Xubuntu 20.04 23rd March and 24th March daily build. Using Martin Wimpress QuickEMU setup. Installation part of xubuntu is working fine. But after install and reboot, you get the login box. I type in the password for the user and then just get a black screen and mouse cursor, no other error boxes or gui. Have tested my QuickEMU setup on ubuntu-mate and do not see this issue, only on Xubuntu daily builds do I see this issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu21 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' Date: Tue Mar 24 16:40:12 2020 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Red Hat, Inc. Virtio GPU [1af4:1050] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. Virtio GPU [1af4:1100] InstallationDate: Installed on 2020-03-24 (0 days ago) InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200324) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Keyboard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-18-generic root=UUID=4b1c21e9-1325-435b-9ade-04263b901e6d ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvrrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.100-4 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.7-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1868780/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1670494] Re: 'wpa_supplicant -D nl80211 -W' hangs with some Intel cards
This is still broken in Artful, but is fixed in Bionic.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1670494
Title:
'wpa_supplicant -D nl80211 -W' hangs with some Intel cards
Status in wpa package in Ubuntu:
Confirmed
Bug description:
init_wpa_supplicant() in /etc/wpa_supplicant/functions.sh runs
wpa_supplicant with the -W option, which causes it to wait for wpa_cli
to attach. init_wpa_supplicant() then attaches wpa_cli to
wpa_supplicant.
When the nl80211 driver is used with some Intel cards, wpa_supplicant
automatically defines a second p2p_dev_${WPA_IFACE} interface. If
multiple interfaces are defined in wpa_supplicant, then wpa_supplicant
will wait for multiple wpa_cli instances to attach. Since
init_wpa_supplicant() only attaches a single wpa_cli process, this
causes wpa_supplicant to hang, which ultimately leads to a timeout and
causes interface configuration to fail.
This has been fixed upstream:
http://lists.infradead.org/pipermail/hostap/2015-December/034410.html
And also in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833402
However, the updated wpa_supplicant has not made it to Ubuntu (not
even Zesty), and the "-m ''" workaround mentioned in the mailing list
thread associated with the upstream fix does not work with the version
of wpa_supplicant that comes with Ubuntu.
Could the P2P patches that were merged into Debian be merged into
Ubuntu?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1670494/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1590590] Re: Touchpad not recognized on Dell Latitude E7470 Ultrabook
No. If I monitor interrupts, the Alps device actually stops sending interrupts when the touchpad or trackstick stutters. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1590590 Title: Touchpad not recognized on Dell Latitude E7470 Ultrabook Status in linux package in Ubuntu: Triaged Status in systemd package in Ubuntu: New Status in xserver-xorg-input-synaptics package in Ubuntu: Confirmed Bug description: Expected: Touchpad settings available in Mouse & Touchpad Settings dialog Actual result: Touchpad settings missing entirely Details: The touchpad on my Dell Ultrabook (Latitude E7470) functions mostly. The settings for the touchpad are not available at all in the Mouse and Touchpad settings (see http://i.imgur.com/YRGiOrj.png). Two-finger scrolling works as expected except it's using "Natural Scrolling" by default and there is no way to change it. xinput list does not display a touchpad at all: ⎡ Virtual core pointerid=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4[slave pointer (2)] ⎜ ↳ ELAN Touchscreenid=11 [slave pointer (2)] ⎜ ↳ ImPS/2 Generic Wheel Mouse id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Power Buttonid=6[slave keyboard (3)] ↳ Video Bus id=7[slave keyboard (3)] ↳ Power Buttonid=8[slave keyboard (3)] ↳ Sleep Buttonid=9[slave keyboard (3)] ↳ Integrated_Webcam_FHD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboardid=12 [slave keyboard (3)] ↳ Dell WMI hotkeysid=14 [slave keyboard (3)] ↳ DELL Wireless hotkeys id=15 [slave keyboard (3)] /proc/bus/input/devices lists the device as a "Generic Wheel Mouse" Output of `lsb_release -rd`: Description: Ubuntu 16.04 LTS Release: 16.04 xserver-xorg-input-synaptics version information: xserver-xorg-input-synaptics: Installed: 1.8.2-1ubuntu3 Candidate: 1.8.2-1ubuntu3 Version table: *** 1.8.2-1ubuntu3 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1590590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1670494] [NEW] 'wpa_supplicant -D nl80211 -W' hangs with some Intel cards
Public bug reported:
init_wpa_supplicant() in /etc/wpa_supplicant/functions.sh runs
wpa_supplicant with the -W option, which causes it to wait for wpa_cli
to attach. init_wpa_supplicant() then attaches wpa_cli to
wpa_supplicant.
When the nl80211 driver is used with some Intel cards, wpa_supplicant
automatically defines a second p2p_dev_${WPA_IFACE} interface. If
multiple interfaces are defined in wpa_supplicant, then wpa_supplicant
will wait for multiple wpa_cli instances to attach. Since
init_wpa_supplicant() only attaches a single wpa_cli process, this
causes wpa_supplicant to hang, which ultimately leads to a timeout and
causes interface configuration to fail.
This has been fixed upstream:
http://lists.infradead.org/pipermail/hostap/2015-December/034410.html
And also in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833402
However, the updated wpa_supplicant has not made it to Ubuntu (not even
Zesty), and the "-m ''" workaround mentioned in the mailing list thread
associated with the upstream fix does not work with the version of
wpa_supplicant that comes with Ubuntu.
Could the P2P patches that were merged into Debian be merged into
Ubuntu?
** Affects: wpa (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1670494
Title:
'wpa_supplicant -D nl80211 -W' hangs with some Intel cards
Status in wpa package in Ubuntu:
New
Bug description:
init_wpa_supplicant() in /etc/wpa_supplicant/functions.sh runs
wpa_supplicant with the -W option, which causes it to wait for wpa_cli
to attach. init_wpa_supplicant() then attaches wpa_cli to
wpa_supplicant.
When the nl80211 driver is used with some Intel cards, wpa_supplicant
automatically defines a second p2p_dev_${WPA_IFACE} interface. If
multiple interfaces are defined in wpa_supplicant, then wpa_supplicant
will wait for multiple wpa_cli instances to attach. Since
init_wpa_supplicant() only attaches a single wpa_cli process, this
causes wpa_supplicant to hang, which ultimately leads to a timeout and
causes interface configuration to fail.
This has been fixed upstream:
http://lists.infradead.org/pipermail/hostap/2015-December/034410.html
And also in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833402
However, the updated wpa_supplicant has not made it to Ubuntu (not
even Zesty), and the "-m ''" workaround mentioned in the mailing list
thread associated with the upstream fix does not work with the version
of wpa_supplicant that comes with Ubuntu.
Could the P2P patches that were merged into Debian be merged into
Ubuntu?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1670494/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started when using ntpdate
I don't think -u would be necessary if /etc/network/if-up.d/ntpdate were using the correct lock file (/var/lock/ntpdate vs /run/lock/ntpdate, as I pointed out in comment #27). But I do agree that either adding -u or fixing the lock file path would be a simple solution to this problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started when using ntpdate Status in init-system-helpers package in Ubuntu: Confirmed Status in ntp package in Ubuntu: Won't Fix Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started when using ntpdate
Yes, it looks to me like sntp is a sufficient replacement for ntpdate. However, sntp is not currently packaged for Debian or Ubuntu: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793837 In addition, prior to that bug being introduced, sntp was included in the 'ntp' package, so sntp could not be installed without installing ntpd. It would be useful to be able to install sntp so it can be used for troubleshooting even when using systemd-timesyncd or chrony or another ntp daemon. Could you add sntp back to the build and package it in a separate 'sntp' package? ** Bug watch added: Debian Bug tracker #793837 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793837 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started when using ntpdate Status in init-system-helpers package in Ubuntu: Confirmed Status in ntp package in Ubuntu: Won't Fix Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started when using ntpdate
My original issue is definitely a duplicate of Bug #1575572 and the fix for that bug solves the specific problem described in Comment #8. The issues described by Lars Kollstedt and others are a separate issue ... My original issue was that systemd would not start ntp.service if /etc/network/if-up.d/ntpdate was called before systemd started ntp.service on its own ... This new issue is that ntpd will not start if /etc/network/if-up.d/ntpdate is called multiple times (due to multiple network interfaces being brought up), and an ntpdate command is still running when ntpd is started. I believe this new issue is caused by the fact that /etc/network/if- up.d/ntpdate uses /run/lock/ntpdate as its lock file, but /etc/init.d/ntp uses /var/lock/ntpdate as its lock file. I believe that using the same lock file in both of those scripts should fix this issue. Or, as was mentioned in several comments, removing ntpdate or disabling /etc/network/if-up.d/ntpdate (and if necessary using `ntpd -q` instead of ntpdate to step the clock) should also fix it. In my case, the reason to have ntpdate installed is for testing/troubleshooting purposes. As far as I can tell, ntpd does NOT have any options that are equivalent to `ntpdate -qu ` or `ntpdate -du `. Since ntpdate is being deprecated, should I file a feature request against ntpd to have equivalent options added to ntpd? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started when using ntpdate Status in init-system-helpers package in Ubuntu: Confirmed Status in ntp package in Ubuntu: Won't Fix Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started when using ntpdate
Aha! I've found the issue. /etc/network/if-up.d/ntpdate is called when each network interface comes up. This happens before network.target is reached, so it happens before ntp.service would normally be automatically started by systemd. /etc/network/if-up.d/ntpdate calls `invoke-rc.d ntp stop`, then it runs ntpdate, then it calls `invoke-rc.d ntp start`. `invoke-rc.d ntp stop` runs `systemctl stop ntp.service`, which causes systemd to cancel the ntp.service start task that was automatically scheduled to happen after network.target. `invoke-rc.d ntp start` calls `/sbin/runlevel` to determine the current runlevel so that it can verify the existence of a /etc/rc?.d/S??ntp symlink for the current runlevel. However, `/sbin/runlevel` returns "unknown" because systemd has not reached multi-user.target yet. Therefore, invoke-rc.d determines that the appropriate /etc/rc?.d/S??ntp symlink does not exist, so it does not call `systemctl start ntp.service` to start ntp. Changing /etc/network/if-up.d/ntpdate so that it calls `systemctl start ntp.service` instead of `invoke-rc.d ntp start` fixes the problem. However, I think I would consider this to be a bug in invoke-rc.d and not ntpdate, since invoke-rc.d simply does not work properly when systemd is being used and invoke-rc.d is called at boot time. At the very least, I would think invoke-rc.d should document that this is unsupported, and it should detect and report this condition if invoke- rc.d is called at boot time (rather than just silently failing). ** Also affects: init-system-helpers (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started when using ntpdate Status in init-system-helpers package in Ubuntu: New Status in ntp package in Ubuntu: Confirmed Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started by systemd
** Attachment added: "list-deps.txt" https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596/+attachment/4654853/+files/list-deps.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started by systemd Status in ntp package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Incomplete Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started by systemd
Attached. Also attached the output of `systemctl list-dependencies` in case that helps any. $ systemctl status ntp ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 03 19:28:45 Fusion systemd[1]: Stopped LSB: Start NTP daemon. May 03 19:28:48 Fusion systemd[1]: Stopped LSB: Start NTP daemon. $ systemctl is-enabled ntp ntp.service is not a native service, redirecting to systemd-sysv-install Executing /lib/systemd/systemd-sysv-install is-enabled ntp enabled ** Attachment added: "journal.txt" https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596/+attachment/4654852/+files/journal.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started by systemd Status in ntp package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Incomplete Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] Re: ntpd not started by systemd
I came across a box that was running Ubuntu 15.10 with ntpd. systemd was automatically starting ntpd on boot on that system: # systemctl status ntp ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp) Active: active (running) since Sun 2016-04-24 14:48:26 EDT; 1 weeks 1 days ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/ntp.service └─849 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:115 Apr 24 14:44:41 host systemd[1]: Starting LSB: Start NTP daemon... Apr 24 14:44:41 host ntp[894]: * Starting NTP server ntpd Apr 24 14:48:26 host ntp[894]: lockfile creation failed: exceeded maximum number of lock attempts Apr 24 14:48:26 host ntp[894]: ...done. Apr 24 14:48:26 host systemd[1]: Started LSB: Start NTP daemon. After updating to 16.04 (ntp:amd64 1:4.2.6.p5+dfsg-3ubuntu8.2 -> 1:4.2.8p4+dfsg-3ubuntu5, systemd:amd64 225-1ubuntu9.1 -> 229-4ubuntu4, systemd-sysv:amd64 225-1ubuntu9.1 -> 229-4ubuntu4), systemd no longer starts ntpd on boot: # systemctl status ntp ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 23:22:37 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 23:22:37 host systemd[1]: Stopped LSB: Start NTP daemon. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started by systemd Status in ntp package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577596] [NEW] ntpd not started by systemd
Public bug reported: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd Binary file systemd-networkd matches Binary file systemd-timedated matches Binary file systemd-timesyncd matches What else can I do to debug this further? ** Affects: ntp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started by systemd Status in ntp package in Ubuntu: New Bug description: After updating from 14.04 to 16.04 on a number of my systems, ntpd no longer starts at boot on any of those systems. `systemctl status ntp` shows: ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon. May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon. Manually starting it using `systemctl start ntp` works fine. However, systemd does not seem to want to start it automatically at boot time. As best as I can tell based on trial and error, there is something special about the combination of the service being named "ntp.service" and the service depending on network.target. However, I haven't been able to identify exactly what is causing this. If I copy the init script to any other name, everything works fine: cp /etc/init.d/ntp /etc/init.d/ntpd Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd" systemctl enable ntpd # After a reboot, ntpd.service is started, but ntp.service is not. If I remove "$network" from the "# Required-Start: $network $remote_fs $syslog" line in /etc/init.d/ntp, then systemd starts it automatically ... But of course it is started before the network comes up, so it fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO echo "script was run" >> /ntp.log If I rename that same dummy script to /etc/init.d/ntp2, it is started automatically at boot. However, grepping the systemd source code and my systemd config files for ntp doesn't seem to find anything that might cause this behavior: /etc/systemd# grep -iR ntp * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExec
[Touch-packages] [Bug 295448] Re: apt documentation for APT::Default-Release is not clear regarding security updates
You can also set Apt::Default-Release to the Version instead of the Suite. In other words, 'Apt::Default-Release "16.04";' will match all of the package sources for xenial. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/295448 Title: apt documentation for APT::Default-Release is not clear regarding security updates Status in apt package in Ubuntu: Confirmed Bug description: Binary package hint: apt This is related to all versions before Hardy (include). I haven't tested this on Intrepid so I'm not sure about those versions after Hardy. According to apt_preferences manpage, the target release can be set on the apt-get command line or in the APT configuration file /etc/apt/apt.conf, and "APT::Default-Release "stable";" is given out as an example. This is a very common and popular practice used in Debian community to set the default release and using apt-pin, but doing this in Ubuntu leads to serious security impact with no obvious warning. After setting APT::Default-Release to "hardy", which is the "Suite" name for main hardy source, no security fixes nor updates would be installed unless their priorities are also set explicitly in apt_preferences. This is because that in Ubuntu's world, security fixes are from "hardy-security" source and other updates are from "hardy-updates" source, which bear different "Suite" from the main source. Setting APT::Default-Release rises the priority of packages from main source to 990, but doesn't cover packages from hardy- security and hardy-updates, so the latter are ignored since their packages now has lower priority (priority 500 only) than those old ones in main source (990). I set APT::Default-Release to "hardy" on Sep this year until I found this problem today. Removed that setting and I'm surprised to found that I can install 46 security fixes and updates accumulated. Which is pretty sad to me that got known I haven't got security fixes for more than 2 months. This is a radical deviation from the Debian practice. In Debian all security fixes and updates bear the same "Suite" (etch or lenny) so setting APT::Default-Release to "etch" covers all security fixes and updates. I think it's unlikely that Ubuntu changes the organization of it's source, so at least a fix to this problem is patching the apt_preferences manpage, alerting people not to use APT::Default- Release like they have used this in Debian and the reason and the following impacts. Version information of my apt from Hardy: Architecture: i386 Version: 0.7.9ubuntu17.1 Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/295448/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
@robert-katzschmann: Make sure wpa_cli is running: # ps aux | grep wpa /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -W -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf /sbin/wpa_cli -B -P /run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action If it is, then check /var/log/syslog - it should contain something like: wpa_supplicant[11998]: wlan0: CTRL-EVENT-CONNECTED - Connection to 18:1b:eb:b7:4a:27 completed [id=0 id_str=default] wpa_action: WPA_IFACE=wlan0 WPA_ACTION=CONNECTED wpa_action: WPA_ID=0 WPA_ID_STR=default WPA_CTRL_DIR=/var/run/wpa_supplicant wpa_action: ifup wlan0=default dhclient: Internet Systems Consortium DHCP Client 4.3.1 I'm guessing one or more of the above syslog messages will be missing ... knowing which messages are missing will help us determine the cause of your problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Committed Status in ifupdown source package in Wily: Fix Committed Bug description: [Impact] * In some configurations recurrent ifup/down calls are broken due to a false-positive recursion detection. * In certain situations it leaves interfaces unconfigured (in this case: WLAN interface connected to WiFi network, but dhcp fails). [Test Case] * Setup wpa-roam configuration based on what is in comment #6 * Wait until wpa_supplicant connects to a wifi network * Run ifconfig to check if the WLAN interface received dhcp info * Expected result: WLAN is fully configured according to dhcp settings * Actual result: WLAN is connected to WiFi but not configured [Regression Potential] * Fixed upstream, fix present in Xenial. * Debdiffs contain a backport of an upstream fix. [Other Info] * Original bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
ifupdown 0.7.54ubuntu1.3 fixes this bug for me in Wily. @dbilunov: Would you mind testing the trusty-proposed package? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Committed Status in ifupdown source package in Wily: Fix Committed Bug description: [Impact] * In some configurations recurrent ifup/down calls are broken due to a false-positive recursion detection. * In certain situations it leaves interfaces unconfigured (in this case: WLAN interface connected to WiFi network, but dhcp fails). [Test Case] * Setup wpa-roam configuration based on what is in comment #6 * Wait until wpa_supplicant connects to a wifi network * Run ifconfig to check if the WLAN interface received dhcp info * Expected result: WLAN is fully configured according to dhcp settings * Actual result: WLAN is connected to WiFi but not configured [Regression Potential] * Fixed upstream, fix present in Xenial. * Debdiffs contain a backport of an upstream fix. [Other Info] * Original bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545363] Re: wpa-roam does not support logical "master" interfaces
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545766 ** Bug watch added: Debian Bug tracker #545766 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545766 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545363 Title: wpa-roam does not support logical "master" interfaces Status in wpa package in Ubuntu: Incomplete Bug description: There are situations where I have multiple APs (living on separate networks) in range simultaneously and I need to be able to manually choose between them (to manually move between those separate networks). To handle this, I have multiple wpa_supplicant config files for each of the APs, and I use logical interfaces in /etc/network/interfaces to select the appropriate config file. For example: iface public inet manual wpa-conf /etc/wpa_supplicant/public.conf iface private inet manual wpa-conf /etc/wpa_supplicant/private.conf To select the appropriate AP, I simply run `ifup wlan0=public` or `ifup wlan0=private`. This part works fine. However, I would like to change the "wpa-conf" lines in the above example to use "wpa-roam" instead, so I can also handle roaming in conjunction with multiple wpa_supplicant config files. Unfortunately this doesn't work. When the "master" interface is already using a logical interface in /etc/network/interfaces, wpa-roam fails to load the logical interface specified by id_str. The problem is that the ifup() function in functions.sh runs `grep -q "^$WPA_IFACE=$WPA_IFACE" "$IFSTATE_FILE"` to determine if the interface is already up, then runs /sbin/ifup either with or without ' --force' depending on whether the interface is "up". If the "master" interface is defined in /etc/network/interfaces as a logical interface rather than a physical interface, then grep will not match, '--force' will not be used, and /sbin/ifup will fail because the interface is already configured and '--force' was not used. The attached patch fixes this issue by running `ifquery` to determine whether the physical interface is currently configured as a wpasupplicant "master" interface and needs the '--force' argument to /sbin/ifup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545363/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
@Dariusz: Works for me on Wily. Nice find, this is a much better fix than my proposed patch. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in wpa package in Ubuntu: Confirmed Bug description: [Impact] * In some configurations recurrent ifup/down calls are broken due to a false-positive recursion detection. * In certain situations it leaves interfaces unconfigured (in this case: WLAN interface connected to WiFi network, but dhcp fails). [Test Case] * Setup wpa-roam configuration based on what is in comment #6 * Wait until wpa_supplicant connects to a wifi network * Run ifconfig to check if the WLAN interface received dhcp info * Expected result: WLAN is fully configured according to dhcp settings * Actual result: WLAN is connected to WiFi but not configured [Regression Potential] * Fixed upstream, fix present in Xenial. * Debdiffs contain a backport of an upstream fix. [Other Info] * Original bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
See bug #1545363 - my patch for that bug happens to remove the use of the ifstate file. However, fixing that does not solve the "ifup: recursion detected ..." issue. The environment variable still needs to be removed to fix the recursion issue. After thinking about it some more, I think it may make more sense to unset the variable in /etc/wpa_supplicant/ifupdown.sh rather than /etc/wpa_supplicant/functions.sh (so the variable is removed from the wpa_supplicant daemon's environment, rather than being removed each time wpa_action calls ifup or ifdown). This new attached patch file does this. Let me know when you have something for me to test. Thanks! ** Attachment added: "patch2" https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+attachment/4572849/+files/patch2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in wpa package in Ubuntu: Confirmed Bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
Oops ... missed "inet dhcp" on the "iface dhcp_dns" line above. That line should be: iface dhcp_dns inet dhcp -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in wpa package in Ubuntu: Confirmed Bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545363] Re: wpa-roam does not support logical "master" interfaces
** Description changed: There are situations where I have multiple APs (living on separate networks) in range simultaneously and I need to be able to manually choose between them (to manually move between those separate networks). To handle this, I have multiple wpa_supplicant config files for each of the APs, and I use logical interfaces in /etc/network/interfaces to select the appropriate config file. For example: iface public inet manual - wpa-conf /etc/wpa_supplicant/public.conf + wpa-conf /etc/wpa_supplicant/public.conf iface private inet manual - wpa-conf /etc/wpa_supplicant/private.conf + wpa-conf /etc/wpa_supplicant/private.conf To select the appropriate AP, I simply run `ifup wlan0=public` or `ifup wlan0=private`. This part works fine. However, I would like to change the "wpa-conf" lines in the above example to use "wpa-roam" instead, so I can also handle roaming in conjunction with multiple wpa_supplicant config files. Unfortunately this doesn't work. When the "master" interface is already using a logical interface in /etc/network/interfaces, wpa-roam fails to load the logical interface specified by id_str. The problem is that the ifup() function in functions.sh runs `grep -q "^$WPA_IFACE=$WPA_IFACE" "$IFSTATE_FILE"` to determine if the interface is already up, then runs /sbin/ifup either with or without '--force' depending on whether the interface is "up". If the "master" interface is defined in /etc/network/interfaces as a logical interface rather than a physical interface, then grep will not match, '--force' will not be used, and /sbin/ifup will fail because the interface is already configured and '--force' was not used. The attached patch fixes this issue by running `ifquery` to determine - whether the physical interface is currently up and configured as a - wpasupplicant "master" interface, and will run /sbin/ifup with '--force' - even if the "master" interface is a logical interface in - /etc/network/interfaces. If the physical interface is already up but is - not configured as a "master" interface, then it is likely we received - two "CONNECT" events without a "DISCONNECT" between them, so `ifdown` is - run on the old logical interface before `ifup` is run on the new one. + whether the physical interface is currently configured as a + wpasupplicant "master" interface and needs the '--force' argument to + /sbin/ifup. ** Attachment added: "patch" https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545363/+attachment/4572525/+files/patch ** Patch removed: "patch" https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545363/+attachment/4571280/+files/patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545363 Title: wpa-roam does not support logical "master" interfaces Status in wpa package in Ubuntu: New Bug description: There are situations where I have multiple APs (living on separate networks) in range simultaneously and I need to be able to manually choose between them (to manually move between those separate networks). To handle this, I have multiple wpa_supplicant config files for each of the APs, and I use logical interfaces in /etc/network/interfaces to select the appropriate config file. For example: iface public inet manual wpa-conf /etc/wpa_supplicant/public.conf iface private inet manual wpa-conf /etc/wpa_supplicant/private.conf To select the appropriate AP, I simply run `ifup wlan0=public` or `ifup wlan0=private`. This part works fine. However, I would like to change the "wpa-conf" lines in the above example to use "wpa-roam" instead, so I can also handle roaming in conjunction with multiple wpa_supplicant config files. Unfortunately this doesn't work. When the "master" interface is already using a logical interface in /etc/network/interfaces, wpa-roam fails to load the logical interface specified by id_str. The problem is that the ifup() function in functions.sh runs `grep -q "^$WPA_IFACE=$WPA_IFACE" "$IFSTATE_FILE"` to determine if the interface is already up, then runs /sbin/ifup either with or without ' --force' depending on whether the interface is "up". If the "master" interface is defined in /etc/network/interfaces as a logical interface rather than a physical interface, then grep will not match, '--force' will not be used, and /sbin/ifup will fail because the interface is already configured and '--force' was not used. The attached patch fixes this issue by running `ifquery` to determine whether the physical interface is currently configured as a wpasupplicant "master" interface and needs the '--force' argument to /sbin/ifup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545363/+subscriptions -- Mailing list: https://launchpad.net/~touch-pac
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
My configuration:
/etc/network/interfaces
auto wlan0
iface wlan0 inet manual
wpa-driver wext
wpa-roam /etc/wpa_supplicant/wpa.conf
wpa-roam-default-iface dhcp
iface dhcp inet dhcp
dns-nameservers 8.8.8.8 8.8.4.4
iface dhcp_dns
/etc/wpa_supplicant/wpa.conf
network={
ssid="x"
priority=10
key_mgmt=WPA-PSK
psk="..."
id_str="dhcp_dns"
}
network={
ssid="y"
priority=9
key_mgmt=WPA-PSK
psk="..."
}
After connecting to either the x or y networks, wpa_supplicant calls
`wpa_action connect` which calls `ifup wlan0=dhcp_dns` or `ifup
wlan0=dhcp`, which fails with "ifup: recursion detected for parent
interface wlan0 in post-up phase". Therefore, dhclient is never run, so
wlan0 never gets an IP address.
Note that the wpa_supplicant daemon is started by the /etc/network/if-
up.d/wpasupplicant script, and it inherits the environment from `ifup
wlan0` (including the environment variable used to detect recursion).
`wpa_action connect` then inherits the environment from wpa_supplicant,
and `ifup wlan0=dhcp` inherits it from wpa_action, hence the error from
ifup.
I understand that this variable is meant to avoid certain race
conditions, but I don't believe the type of race condition reported in
bug #1337873 is applicable to this situation. Because wpa_supplicant is
started by ifup itself (and not a boot script), there is no way for the
`ifup wlan0` and `ifup wlan0=dhcp` to be called out of order, so there
is no chance of a race condition. However, maybe I'm missing something
here. Could you explain how the wpa-roam implementation could play
along with ifupdown given that it is started by ifup itself and needs to
call ifup to reconfigure the interface?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1545302
Title:
wpa-roam broken by fix for ifupdown #1337873
Status in wpa package in Ubuntu:
Confirmed
Bug description:
The following versions of ifupdown introduced a recursion check using
"IFUPDOWN_" environment variables along with a new locking mechanism
for ifup (see #1337873):
0.7.47.2ubuntu4.2 (in Trusty)
0.7.54ubuntu1.1 (in Wily)
0.7.54ubuntu2 (in Xenial)
This recursion check breaks the wpa-roam feature of wpasupplicant,
preventing it from loading the logical interface specified by id_str
after associating with an AP. Specifically, after upgrading to one of
the above ifupdown versions, the '/sbin/ifup -v --force
"$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in
functions.sh fails with an "ifup: recursion detected for parent
interface wlan0 in post-up phase" error.
To fix the issue, functions.sh needs to run `unset
"IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from
detecting the recursion. The attached patch implements this change.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] Re: wpa-roam broken by fix for ifupdown #1337873
Updating my patch ... The environment variable also needs to be unset before calling ifdown. ** Attachment added: "patch" https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+attachment/4572496/+files/patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in wpa package in Ubuntu: Confirmed Bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545363] [NEW] wpa-roam does not support logical "master" interfaces
Public bug reported: There are situations where I have multiple APs (living on separate networks) in range simultaneously and I need to be able to manually choose between them (to manually move between those separate networks). To handle this, I have multiple wpa_supplicant config files for each of the APs, and I use logical interfaces in /etc/network/interfaces to select the appropriate config file. For example: iface public inet manual wpa-conf /etc/wpa_supplicant/public.conf iface private inet manual wpa-conf /etc/wpa_supplicant/private.conf To select the appropriate AP, I simply run `ifup wlan0=public` or `ifup wlan0=private`. This part works fine. However, I would like to change the "wpa-conf" lines in the above example to use "wpa-roam" instead, so I can also handle roaming in conjunction with multiple wpa_supplicant config files. Unfortunately this doesn't work. When the "master" interface is already using a logical interface in /etc/network/interfaces, wpa-roam fails to load the logical interface specified by id_str. The problem is that the ifup() function in functions.sh runs `grep -q "^$WPA_IFACE=$WPA_IFACE" "$IFSTATE_FILE"` to determine if the interface is already up, then runs /sbin/ifup either with or without '--force' depending on whether the interface is "up". If the "master" interface is defined in /etc/network/interfaces as a logical interface rather than a physical interface, then grep will not match, '--force' will not be used, and /sbin/ifup will fail because the interface is already configured and '--force' was not used. The attached patch fixes this issue by running `ifquery` to determine whether the physical interface is currently up and configured as a wpasupplicant "master" interface, and will run /sbin/ifup with '--force' even if the "master" interface is a logical interface in /etc/network/interfaces. If the physical interface is already up but is not configured as a "master" interface, then it is likely we received two "CONNECT" events without a "DISCONNECT" between them, so `ifdown` is run on the old logical interface before `ifup` is run on the new one. ** Affects: wpa (Ubuntu) Importance: Undecided Status: New ** Patch added: "patch" https://bugs.launchpad.net/bugs/1545363/+attachment/4571280/+files/patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545363 Title: wpa-roam does not support logical "master" interfaces Status in wpa package in Ubuntu: New Bug description: There are situations where I have multiple APs (living on separate networks) in range simultaneously and I need to be able to manually choose between them (to manually move between those separate networks). To handle this, I have multiple wpa_supplicant config files for each of the APs, and I use logical interfaces in /etc/network/interfaces to select the appropriate config file. For example: iface public inet manual wpa-conf /etc/wpa_supplicant/public.conf iface private inet manual wpa-conf /etc/wpa_supplicant/private.conf To select the appropriate AP, I simply run `ifup wlan0=public` or `ifup wlan0=private`. This part works fine. However, I would like to change the "wpa-conf" lines in the above example to use "wpa-roam" instead, so I can also handle roaming in conjunction with multiple wpa_supplicant config files. Unfortunately this doesn't work. When the "master" interface is already using a logical interface in /etc/network/interfaces, wpa-roam fails to load the logical interface specified by id_str. The problem is that the ifup() function in functions.sh runs `grep -q "^$WPA_IFACE=$WPA_IFACE" "$IFSTATE_FILE"` to determine if the interface is already up, then runs /sbin/ifup either with or without ' --force' depending on whether the interface is "up". If the "master" interface is defined in /etc/network/interfaces as a logical interface rather than a physical interface, then grep will not match, '--force' will not be used, and /sbin/ifup will fail because the interface is already configured and '--force' was not used. The attached patch fixes this issue by running `ifquery` to determine whether the physical interface is currently up and configured as a wpasupplicant "master" interface, and will run /sbin/ifup with '-- force' even if the "master" interface is a logical interface in /etc/network/interfaces. If the physical interface is already up but is not configured as a "master" interface, then it is likely we received two "CONNECT" events without a "DISCONNECT" between them, so `ifdown` is run on the old logical interface before `ifup` is run on the new one. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545363/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packag
[Touch-packages] [Bug 1541235] Re: ifupdown don't start dhclient on mode wifi wpa-roam
*** This bug is a duplicate of bug 1545302 *** https://bugs.launchpad.net/bugs/1545302 ** This bug has been marked a duplicate of bug 1545302 wpa-roam broken by fix for ifupdown #1337873 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1541235 Title: ifupdown don't start dhclient on mode wifi wpa-roam Status in ifupdown package in Ubuntu: New Bug description: I'm use WiFi roaming with wpa-supplicant my interfaces file: iface wlan0 inet manual wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf iface default inet dhcp fragment syslog's file with good work: ... Feb 3 10:14:36 thinkpad wpa_action: WPA_IFACE=wlan0 WPA_ACTION=CONNECTED Feb 3 10:14:36 thinkpad wpa_action: WPA_ID=0 WPA_ID_STR= WPA_CTRL_DIR=/var/run/wpa_supplicant Feb 3 10:14:36 thinkpad wpa_action: network settings not defined for default in /etc/network/interfaces Feb 3 10:14:36 thinkpad wpa_action: ifup wlan0=default Feb 3 10:14:36 thinkpad dhclient: Internet Systems Consortium DHCP Client 4.2.4 Feb 3 10:14:36 thinkpad dhclient: Copyright 2004-2012 Internet Systems Consortium. Feb 3 10:14:36 thinkpad dhclient: All rights reserved. Feb 3 10:14:36 thinkpad dhclient: For info, please visit https://www.isc.org/software/dhcp/ Feb 3 10:14:36 thinkpad dhclient: Feb 3 10:14:36 thinkpad dhclient: Listening on LPF/wlan0/xx:xx:xx:xx:xx:xx Feb 3 10:14:36 thinkpad dhclient: Sending on LPF/wlan0/xx:xx:xx:xx:xx:xx Feb 3 10:14:36 thinkpad dhclient: Sending on Socket/fallback Feb 3 10:14:36 thinkpad dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3 (xid=0x22baa721) Feb 3 10:14:36 thinkpad dhclient: DHCPREQUEST of 10.0.0.58 on wlan0 to 255.255.255.255 port 67 (xid=0x21a7ba22) Feb 3 10:14:36 thinkpad dhclient: DHCPOFFER of 10.0.0.58 from 10.0.0.254 Feb 3 10:14:36 thinkpad dhclient: DHCPACK of 10.0.0.58 from 10.0.0.254 Feb 3 10:14:36 thinkpad dhclient: bound to 10.0.0.58 -- renewal in 1620 seconds. Feb 3 10:14:36 thinkpad wpa_action: creating sendsigs omission pidfile: /run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid ... after the upgrade to version 0.7.47.2ubuntu4.3 dhclient don't start syslog: ... Feb 2 19:52:12 thinkpad wpa_action: ifup wlan0=default Feb 2 19:52:12 thinkpad wpa_action: creating sendsigs omission pidfile: /run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid ... I have to run the dhclient manually after the downgrade to version 0.7.47.2ubuntu4 all work good To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1541235/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1545302] [NEW] wpa-roam broken by fix for ifupdown #1337873
Public bug reported: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. ** Affects: wpa (Ubuntu) Importance: Undecided Status: Confirmed ** Patch added: "patch" https://bugs.launchpad.net/bugs/1545302/+attachment/4570963/+files/patch ** Description changed: - The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup: + The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1545302 Title: wpa-roam broken by fix for ifupdown #1337873 Status in wpa package in Ubuntu: Confirmed Bug description: The following versions of ifupdown introduced a recursion check using "IFUPDOWN_" environment variables along with a new locking mechanism for ifup (see #1337873): 0.7.47.2ubuntu4.2 (in Trusty) 0.7.54ubuntu1.1 (in Wily) 0.7.54ubuntu2 (in Xenial) This recursion check breaks the wpa-roam feature of wpasupplicant, preventing it from loading the logical interface specified by id_str after associating with an AP. Specifically, after upgrading to one of the above ifupdown versions, the '/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"' command run by wpa_action in functions.sh fails with an "ifup: recursion detected for parent interface wlan0 in post-up phase" error. To fix the issue, functions.sh needs to run `unset "IFDOWN_$WPA_IFACE"` before calling /sbin/ifup to prevent ifup from detecting the recursion. The attached patch implements this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ
I have also verified the fix on Trusty. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Fix Committed Status in rsyslog source package in Utopic: Fix Committed Bug description: Test Case - * Install rsyslog 7.4.4-1ubuntu2.1 on an Ubuntu system that runs inside an OpenVZ container (If necessary, use ProxMox to quickly establish an OpenVZ container environment) * Verify that '$KLogPermitNonKernelFacility on' is set in /etc/rsyslog.conf * Restart rsyslog to make sure any changes to the binaries/config are picked up * Run 'top' and observe that the rsyslogd process is running at 100% CPU. When working properly, the rsyslogd process should generally be idle. - After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ
Pull request has been accepted upstream. Since there are now a bunch of upstream commits involved in the complete fix, I'm attaching an updated 11-fix-infinite-loop-openvz-vms.patch file for the ubuntu packages which contains all the necessary changes. I also posted updated ubuntu package branches here: https://code.launchpad.net/~s-launchpad-paulsd-com/rsyslog/ But feel free to ignore my branch merge requests if you would prefer to update the package branches yourself. ** Patch added: "11-fix-infinite-loop-openvz-vms.patch" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4294715/+files/11-fix-infinite-loop-openvz-vms.patch ** Patch removed: "imklog.patch" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4294218/+files/imklog.patch ** Patch removed: "Upstream fix" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4254548/+files/patch ** Patch removed: "imkmsg.patch" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4294219/+files/imkmsg.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Fix Committed Status in rsyslog source package in Utopic: Fix Committed Bug description: Test Case - * Install rsyslog 7.4.4-1ubuntu2.1 on an Ubuntu system that runs inside an OpenVZ container (If necessary, use ProxMox to quickly establish an OpenVZ container environment) * Verify that '$KLogPermitNonKernelFacility on' is set in /etc/rsyslog.conf * Restart rsyslog to make sure any changes to the binaries/config are picked up * Run 'top' and observe that the rsyslogd process is running at 100% CPU. When working properly, the rsyslogd process should generally be idle. - After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ
** Patch added: "imkmsg.patch" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4294219/+files/imkmsg.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Fix Committed Status in rsyslog source package in Utopic: Fix Committed Bug description: Test Case - * Install rsyslog 7.4.4-1ubuntu2.1 on an Ubuntu system that runs inside an OpenVZ container (If necessary, use ProxMox to quickly establish an OpenVZ container environment) * Verify that '$KLogPermitNonKernelFacility on' is set in /etc/rsyslog.conf * Restart rsyslog to make sure any changes to the binaries/config are picked up * Run 'top' and observe that the rsyslogd process is running at 100% CPU. When working properly, the rsyslogd process should generally be idle. - After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ
Oops, wrong url for the new pull request upstream. It is: https://github.com/rsyslog/rsyslog/pull/198 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Fix Committed Status in rsyslog source package in Utopic: Fix Committed Bug description: Test Case - * Install rsyslog 7.4.4-1ubuntu2.1 on an Ubuntu system that runs inside an OpenVZ container (If necessary, use ProxMox to quickly establish an OpenVZ container environment) * Verify that '$KLogPermitNonKernelFacility on' is set in /etc/rsyslog.conf * Restart rsyslog to make sure any changes to the binaries/config are picked up * Run 'top' and observe that the rsyslogd process is running at 100% CPU. When working properly, the rsyslogd process should generally be idle. - After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ
Sorry, there were two issues: 1) The condition that the fix was testing for (EBADF on read before dropping privileges) was not a reliable indicator of the underlying problem. I should really have tested for EPERM on read after dropping privileges. 2) I only applied the fix to imkmsg, it also needed to be applied to imklog. I've submitted an new pull request upstream: https://github.com/rsyslog/rsyslog/pull/138 ** Patch added: "imklog.patch" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4294218/+files/imklog.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Fix Committed Status in rsyslog source package in Utopic: Fix Committed Bug description: Test Case - * Install rsyslog 7.4.4-1ubuntu2.1 on an Ubuntu system that runs inside an OpenVZ container (If necessary, use ProxMox to quickly establish an OpenVZ container environment) * Verify that '$KLogPermitNonKernelFacility on' is set in /etc/rsyslog.conf * Restart rsyslog to make sure any changes to the binaries/config are picked up * Run 'top' and observe that the rsyslogd process is running at 100% CPU. When working properly, the rsyslogd process should generally be idle. - After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ
Test case: * Install rsyslog 7.4.4-1ubuntu2.1 on an Ubuntu system that runs inside an OpenVZ container (If necessary, use ProxMox to quickly establish an OpenVZ container environment) * Verify that '$KLogPermitNonKernelFacility on' is set in /etc/rsyslog.conf * Restart rsyslog to make sure any changes to the binaries/config are picked up * Run 'top' and observe that the rsyslogd process is running at 100% CPU. When working properly, the rsyslogd process should generally be idle. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU in OpenVZ Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Triaged Status in rsyslog source package in Utopic: Triaged Bug description: After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: Updating to rsyslog - 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU
** Attachment added: "Upstream fix" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+attachment/4254548/+files/patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: Updating to rsyslog - 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU Status in “rsyslog” package in Ubuntu: Confirmed Bug description: After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366829] Re: Updating to rsyslog - 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU
Fixed here: https://github.com/rsyslog/rsyslog/pull/138 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1366829 Title: Updating to rsyslog - 7.4.4-1ubuntu2.1 makes rsyslogd to take all the CPU Status in “rsyslog” package in Ubuntu: Confirmed Bug description: After updating rsyslog from 7.4.4-1ubuntu2 to 7.4.4-1ubuntu2.1 the rsyslogd process started to take all the CPU on my machine. The modification made by this release is described in #127, it is the activation of KLogPermitNonKernelFacility option. I don't know exactly the effect of this option but it seems to have a permanent effect : even after downgrading the package or manually removing the option from /etc/rsyslog.conf the issue remains. My syslog is full of : Sep 8 10:28:40 sentry rsyslogd: imklog: error reading kernel log - shutting down: Bad file descriptor Sep 8 10:28:40 sentry rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor] Sep 8 10:28:46 sentry rsyslogd-2177: rsyslogd[internal_messages]: 519517 messages lost due to rate-limiting I guess this is what causes the CPU load. I am running Ubuntu 14.04.1 LTS in an OpenVZ container on Proxmox 3.2. The kernel is 2.6.32-28-pve --- ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: rsyslog 7.4.4-1ubuntu2.1 PackageArchitecture: amd64 Tags: trusty Uname: Linux 2.6.32-28-pve x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1366829/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
