[Touch-packages] [Bug 1817627] Re: systemd-analyze verify reports failure
This is a scary bug. I was just trying to verify the syntax of a timer file using systemd v237. I got an error message back suggesting something like rm -rf / was attempted to be executed instead! $ sudo systemd-analyze verify /etc/systemd/system/my.timer Attempted to remove disk file system, and we can't allow that. Backporting this fix could help reduce the risk of heart attacks. -- 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/1817627 Title: systemd-analyze verify reports failure Status in Ubuntu Manpage Repository: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: Version 237 and 238 of systemd-analyze have a known issue: https://github.com/systemd/systemd/issues/8592 When will a fix be posted? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-manpage-repository/+bug/1817627/+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
Re: [Touch-packages] [Bug 1618188] Re: systemd journal should be persistent by default: /var/log/journal should be created
> @xnox > "The journald daemon has limits set for logs, meaning they will be > rotated and discarded and should not cause out of disk-space errors." > > What are they? AFAICT it only has limits on the number of files, but > not how big they can overall become. The limits are documented in `man journald.conf`. One of them is " SystemMaxUse=, ", which is based on disk usage, not file size. > I'm also thinking that the duplicate writing of logs could cause other > regressions, one example being where high disk throughput is ongoing and > many things being written to the logs. Thoughts? Additional disk writing is somewhat mitigated by the general increase in disk performance over time in new hardware As one user found here, SSD is about 5x faster than HDD and the newer NVMe SSDs are about 5x faster than the older SSDs. A new NVMe SSD is about 25x faster than an HDD. https://photographylife.com/nvme-vs-ssd-vs-hdd-performance The idea here is to be "safe by default". People are welcome to prioritize performance and reduce logging beyond the defaults. Mark -- 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/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Fix Committed Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * System logs are lost across reboots because they are not stored persistently. [Test Case] * Fresh installations, or upgrades to this version of systemd, should create /var/log/journal and trigger automatic persistent logs. * Users may choose to remove said directory, or disable persistent logging in /etc/systemd/journald.conf [Regression Potential] * Persistent logging by default will cause logs to be flushed from /run to /var/log, meaning there will be less RAM used (/run is tmpfs backed), but increased disk usage (in /var/log). The journald daemon has limits set for logs, meaning they will be rotated and discarded and should not cause out of disk-space errors. [Other Info] * Original bug report After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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 411688] Re: pulseaudio floods network with multicast packets
I ran into this flooding today on Ubuntu 17.10. This "fixed" it, at least temporarily: pactl unload-module module-rtp-send -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/411688 Title: pulseaudio floods network with multicast packets Status in PulseAudio: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio package in Arch Linux: Confirmed Status in pulseaudio package in Debian: Fix Released Bug description: Binary package hint: pulseaudio Since a karmic update last week, when pulseaudio is running it floods the network with multicast packets, to the point where the wireless interface I'm using is so flooded that no other network traffic can be transfered. Here is a snippet of tcpdump -i wlan 0 -n: ---8<--- 01:10:36.532748 IP (tos 0x10, ttl 1, id 23823, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d0f 4000 0111 2d6d 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f9f6 800a ee8e 0x0020: 0071 a980 ed51 a42b 0x0030: 0x0040: 01:10:36.53 IP (tos 0x10, ttl 1, id 23824, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d10 4000 0111 2d6c 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f8b5 800a ee8f 0x0020: 0071 aac0 ed51 a42b 0x0030: 0x0040: 01:10:36.547289 IP (tos 0x10, ttl 1, id 23825, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d11 4000 0111 2d6b 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f774 800a ee90 0x0020: 0071 ac00 ed51 a42b 0x0030: 0x0040: 01:10:36.556725 IP (tos 0x10, ttl 1, id 23826, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d12 4000 0111 2d6a 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f633 800a ee91 0x0020: 0071 ad40 ed51 a42b 0x0030: 0x0040: 01:10:36.561680 IP (tos 0x10, ttl 1, id 23827, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d13 4000 0111 2d69 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f4f2 800a ee92 0x0020: 0071 ae80 ed51 a42b 0x0030: 0x0040: 01:10:36.568984 IP (tos 0x10, ttl 1, id 23828, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d14 4000 0111 2d68 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f3b1 800a ee93 0x0020: 0071 afc0 ed51 a42b 0x0030: 0x0040: 01:10:36.576212 IP (tos 0x10, ttl 1, id 23829, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d15 4000 0111 2d67 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f270 800a ee94 0x0020: 0071 b100 ed51 a42b 0x0030: 0x0040: 01:10:36.588095 IP (tos 0x10, ttl 1, id 23830, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d16 4000 0111 2d66 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 f12f 800a ee95 0x0020: 0071 b240 ed51 a42b 0x0030: 0x0040: 01:10:36.590645 IP (tos 0x10, ttl 1, id 23831, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528 5d17 4000 0111 2d65 0a00 0001 0x0010: e000 0038 b0b0 b6dc 0514 efee 800a ee96 0x0020: 0071 b380 ed51 a42b 0x0030: 0x0040: 01:10:36.605081 IP (tos 0x10, ttl 1, id 23832, offset 0, flags [DF], proto UDP (17), length 1320) 10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292 0x: 4510 0528
[Touch-packages] [Bug 1618188] Re: systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs
I started a policy discussion on ubuntu-devel about whether systemd journal logging should be persistent by default: https://lists.ubuntu.com/archives/ubuntu-devel/2017-November/040031.html I encourage to participate. Non-developers can still participant, but posts will be moderated (that's how I was able to post in the first place.) -- 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/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs Status in systemd package in Ubuntu: Triaged Status in ubuntu-meta package in Ubuntu: Triaged Bug description: After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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 1618188] Re: systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs
@dino99. Because good defaults matter. Being safe by default is important. Being secure by default is important. The "Principle of least surprise" applies here: "In general engineering design contexts, the principle can be taken to mean that a component of a system should behave in a manner consistent with how users of that component are likely to expect it to behave". One reasonable expects their logs to saved through reboot, as system logs have worked that way for the last couple of decades. I didn't think to go create "/var/log/journal" because I trusted Ubuntu to continue to be "safe by default" has it generally has been for years. -- 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/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs Status in systemd package in Ubuntu: Triaged Status in ubuntu-meta package in Ubuntu: Triaged Bug description: After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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 1618188] Re: systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs
@dino99 how was "what most users prefer" prefer determined? Was there a poll? Systemd already has configuration options to limit the growth the the journal. As documented in `man journald.conf`, the defaults are already set to prevent filling up a disk. If there were a poll, I can certainly imagine people voting for having valuable logging kept for review. That has been the policy for syslog for years. I don't see why someone would want to suddenly start throwing away valuable logs at reboot just because the logging backend is now journald instead of syslog. -- 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/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs Status in systemd package in Ubuntu: Triaged Status in ubuntu-meta package in Ubuntu: Triaged Bug description: After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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
Re: [Touch-packages] [Bug 1618188] Re: systemd journal should be persistent by default: /var/log/journal should be created
Thanks for the response, Martin. Where will the public policy discuss take place? Perhaps one possibility for a interim solution is for rsyslog to log to journald by default instead of to disk by default and otherwise maximally direct services to log into journald instead of rsyslog. Mark -- 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/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created Status in systemd package in Ubuntu: Triaged Bug description: After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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 1618188] [NEW] systemd journal should be persistent by default: /var/log/journal should be created
Public bug reported: After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. ** 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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created Status in systemd package in Ubuntu: New Bug description: After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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 1422143] Re: No wifi connection after suspend with systemd due to missing "wpa_cli suspend"
Aberto This is marked as "fixed", but what was the fix? -- 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/1422143 Title: No wifi connection after suspend with systemd due to missing "wpa_cli suspend" Status in One Hundred Papercuts: Fix Released Status in NetworkManager: Unknown Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Wily: Fix Committed Status in wpa source package in Xenial: Fix Released Bug description: Using systemd as my default init system if I resume from suspend my laptop, it doesn't automatically reconnect to the wireless network and it doesn't list the available network connections. The only way to get a wireless connection is to restart the network- manager daemon or going to the gnome-control-center, disable wireless and enable it again. SRU INFORMATION === In some of these cases this bug can be worked around by calling "wpa_cli suspend/resume" before/after suspend, like we used to do with the old pm-utils quirks (/usr/lib/pm-utils/sleep.d/60_wpa_supplicant). This only affects particular hardware, and thus this needs to be tested by affected reporters, there is no general reproducer for arbitrary systems. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu6 Uname: Linux 3.19.0-031900-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.16.1-0ubuntu2 Architecture: amd64 Date: Sun Feb 15 18:27:39 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-10-22 (116 days ago) InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140923) IpRoute: default via 10.0.0.1 dev wlan0 proto static metric 1024 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.36 169.254.0.0/16 dev wlan0 scope link metric 1000 SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-01-13 (32 days ago) nmcli-dev: DEVICE TYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlan0wifi connected/org/freedesktop/NetworkManager/Devices/2 openhost_caldas 09d1f69d-d3da-4978-a69c-d94455db7ecf /org/freedesktop/NetworkManager/ActiveConnection/0 docker0 bridgeunavailable /org/freedesktop/NetworkManager/Devices/3 -- ---- eth0 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- ---- lo loopback unmanaged/org/freedesktop/NetworkManager/Devices/0 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1422143/+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 1422143] Re: No wifi connection after suspend with systemd due to missing "wpa_cli suspend"
This fix works for me: 1. As root, create a file named /etc/systemd/system/resume.service with the following contents: [Unit] Description=Local system resume actions After=suspend.target [Service] Type=oneshot ExecStart=/bin/systemctl restart NetworkManager.service [Install] WantedBy=suspend.target sudo systemctl enable resume.service sudo systemctl daemon-reload Now after a suspend resume, I the Network Manager icon reloads almost instantly, and wifi comes back. You can confirm the action ran by checking it's service log after a resume: journalctl -u resume.service Jun 01 11:29:11 myhost systemd[1]: Starting Local system resume actions... Jun 01 11:29:12 myhost systemd[1]: Started Local system resume actions. If you want to trigger other actions to run at "resume" time, you can add additional "ExecStart=" lines to the file. -- 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/1422143 Title: No wifi connection after suspend with systemd due to missing "wpa_cli suspend" Status in One Hundred Papercuts: Confirmed Status in NetworkManager: Unknown Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Wily: Fix Committed Status in wpa source package in Xenial: Fix Released Bug description: Using systemd as my default init system if I resume from suspend my laptop, it doesn't automatically reconnect to the wireless network and it doesn't list the available network connections. The only way to get a wireless connection is to restart the network- manager daemon or going to the gnome-control-center, disable wireless and enable it again. SRU INFORMATION === In some of these cases this bug can be worked around by calling "wpa_cli suspend/resume" before/after suspend, like we used to do with the old pm-utils quirks (/usr/lib/pm-utils/sleep.d/60_wpa_supplicant). This only affects particular hardware, and thus this needs to be tested by affected reporters, there is no general reproducer for arbitrary systems. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu6 Uname: Linux 3.19.0-031900-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.16.1-0ubuntu2 Architecture: amd64 Date: Sun Feb 15 18:27:39 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-10-22 (116 days ago) InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140923) IpRoute: default via 10.0.0.1 dev wlan0 proto static metric 1024 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.36 169.254.0.0/16 dev wlan0 scope link metric 1000 SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-01-13 (32 days ago) nmcli-dev: DEVICE TYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlan0wifi connected/org/freedesktop/NetworkManager/Devices/2 openhost_caldas 09d1f69d-d3da-4978-a69c-d94455db7ecf /org/freedesktop/NetworkManager/ActiveConnection/0 docker0 bridgeunavailable /org/freedesktop/NetworkManager/Devices/3 -- ---- eth0 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- ---- lo loopback unmanaged/org/freedesktop/NetworkManager/Devices/0 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1422143/+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 1556357] Re: WiFi fails to resume after suspend; Race with wpasupplicant / wpa_cli resume?
I have this problem on a Dell XPS 2013 (Haswell) running Ubuntu 16.04. However, trying to workaround it like results in an error: sudo wpa_cli resume Failed to connect to non-global ctrl_ifname: (nil) error: No such file or directory. This bug is the same as, or similar to: No wifi connection after suspend with systemd due to missing "wpa_cli suspend" https://bugs.launchpad.net/hundredpapercuts/+bug/1422143 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1556357 Title: WiFi fails to resume after suspend; Race with wpasupplicant / wpa_cli resume? Status in network-manager package in Ubuntu: Confirmed Status in wpasupplicant package in Ubuntu: Confirmed Bug description: Hi, I'm constantly having issues where my WiFi connection doesn't re- establish after resuming from suspend. I think it may be a race where the interface isn't ready yet and systemd-sleep calls /lib/systemd /system-sleep/wpasupplicant (which is a wrapper to wpa_cli). I normally restart NetworkManager but then found that calling 'wpa_cli resume' works also. Here's the logs: | Mar 12 13:53:06 ragnar.local kernel: psmouse serio1: synaptics: quirked min/max coordinates: x [1024..5112], y [2024..4832] | Mar 12 13:53:06 ragnar.local kernel: PM: resume of devices complete after 562.709 msecs | Mar 12 13:53:06 ragnar.local kernel: PM: Finishing wakeup. | Mar 12 13:53:06 ragnar.local systemd[1]: Time has been changed | Mar 12 13:53:06 ragnar.local systemd[1066]: Time has been changed | Mar 12 13:53:06 ragnar.local kernel: Restarting tasks ... done. | Mar 12 13:53:06 ragnar.local systemd-sleep[29174]: System resumed. | Mar 12 13:53:06 ragnar.local systemd-sleep[29174]: Failed to connect to non-global ctrl_ifname: (nil) error: No such file or directory | Mar 12 13:53:06 ragnar.local systemd-sleep[29227]: /lib/systemd/system-sleep/wpasupplicant failed with error code 255. | Mar 12 13:53:06 ragnar.local systemd[1]: Started Suspend. | Mar 12 13:53:06 ragnar.local systemd[1]: sleep.target: Unit not needed anymore. Stopping. | Mar 12 13:53:06 ragnar.local systemd[1]: Stopped target Sleep. | Mar 12 13:53:06 ragnar.local systemd[1]: Reached target Suspend. | Mar 12 13:53:06 ragnar.local systemd[1]: suspend.target: Unit is bound to inactive unit systemd-suspend.service. Stopping, too. | Mar 12 13:53:06 ragnar.local NetworkManager[23292]: wake requested (sleeping: yes enabled: yes) | Mar 12 13:53:06 ragnar.local systemd[1]: Stopped target Suspend. | Mar 12 13:53:06 ragnar.local NetworkManager[23292]: waking up... | Mar 12 13:53:06 ragnar.local systemd-logind[662]: Operation 'sleep' finished. | Mar 12 13:53:06 ragnar.local kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready | Mar 12 13:53:06 ragnar.local kernel: iwlwifi :03:00.0: L1 Enabled - LTR Enabled | Mar 12 13:53:06 ragnar.local NetworkManager[23292]: (wlp3s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] | Mar 12 13:53:06 ragnar.local kernel: iwlwifi :03:00.0: L1 Enabled - LTR Enabled | Mar 12 13:53:07 ragnar.local kernel: iwlwifi :03:00.0: L1 Enabled - LTR Enabled | Mar 12 13:53:07 ragnar.local kernel: iwlwifi :03:00.0: L1 Enabled - LTR Enabled | Mar 12 13:53:07 ragnar.local NetworkManager[23292]: NetworkManager state is now DISCONNECTED | Mar 12 13:53:07 ragnar.local kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready | Mar 12 13:53:07 ragnar.local wpa_supplicant[23157]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (none) none | Mar 12 13:53:07 ragnar.local wpa_supplicant[23157]: dbus: Failed to construct signal | Mar 12 13:53:07 ragnar.local wpa_supplicant[23157]: Could not read interface p2p-dev-wlp3s0 flags: No such device | Mar 12 13:53:07 ragnar.local NetworkManager[23292]: (wlp3s0): supplicant interface state: starting -> ready | Mar 12 13:53:07 ragnar.local NetworkManager[23292]: (wlp3s0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] | Mar 12 13:53:07 ragnar.local NetworkManager[23292]: Device 'wlp3s0' has no connection; scheduling activate_check in 0 seconds. | Mar 12 13:53:07 ragnar.local kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready Thanks, Haw --- ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.04 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-04-24 (687 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) Package: wpasupplicant PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.4.0-11.26-generic 4.4.4 RfKill: Error: [Errno 2] No such file or directory
[Touch-packages] [Bug 1422143] Re: No wifi connection after suspend with systemd due to missing "wpa_cli suspend"
I started experiencing this bug after upgrading a Dell XPS 13 2013 (Haswell) to 16.04 and systemd. After a resume, I have to do one of two things to re-connect to wifi: 1. Manually re-enable wifi in NetworkManager menu 2. sudo systemctl restart NetworkManager -- 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/1422143 Title: No wifi connection after suspend with systemd due to missing "wpa_cli suspend" Status in One Hundred Papercuts: Confirmed Status in NetworkManager: Unknown Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Wily: Fix Committed Status in wpa source package in Xenial: Fix Released Bug description: Using systemd as my default init system if I resume from suspend my laptop, it doesn't automatically reconnect to the wireless network and it doesn't list the available network connections. The only way to get a wireless connection is to restart the network- manager daemon or going to the gnome-control-center, disable wireless and enable it again. SRU INFORMATION === In some of these cases this bug can be worked around by calling "wpa_cli suspend/resume" before/after suspend, like we used to do with the old pm-utils quirks (/usr/lib/pm-utils/sleep.d/60_wpa_supplicant). This only affects particular hardware, and thus this needs to be tested by affected reporters, there is no general reproducer for arbitrary systems. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu6 Uname: Linux 3.19.0-031900-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.16.1-0ubuntu2 Architecture: amd64 Date: Sun Feb 15 18:27:39 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-10-22 (116 days ago) InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140923) IpRoute: default via 10.0.0.1 dev wlan0 proto static metric 1024 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.36 169.254.0.0/16 dev wlan0 scope link metric 1000 SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-01-13 (32 days ago) nmcli-dev: DEVICE TYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlan0wifi connected/org/freedesktop/NetworkManager/Devices/2 openhost_caldas 09d1f69d-d3da-4978-a69c-d94455db7ecf /org/freedesktop/NetworkManager/ActiveConnection/0 docker0 bridgeunavailable /org/freedesktop/NetworkManager/Devices/3 -- ---- eth0 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- ---- lo loopback unmanaged/org/freedesktop/NetworkManager/Devices/0 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1422143/+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 425857] Re: pulseaudio rtp.c: sendmsg() failed
I'm getting flooded with these errors on Ubuntu 16.04. My pulseaudo package version is: 1:8.0-0ubuntu3 The exact error that floods my log is: "[null-sink] rtp.c: sendmsg() failed: Invalid argument". Looks like I get it more than 50 times /per second/. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/425857 Title: pulseaudio rtp.c: sendmsg() failed Status in pulseaudio package in Ubuntu: Expired Bug description: Binary package hint: pulseaudio My logs fill up when running any kind of iptables firewalling that prevents sending of these logs. About one a second, constantly while a firewall is enabled - same as the sap.c messages that flood log entries. This seems related to bug #187963, which was supposedly fixed log verbosity in older releases, just not not in Karmic's pulseaudio 0.9.16 train of code. I had reported that it is still an issue in upstream code but much later seems nothing has been done about it. Please push changes to karmic and set in code base for further releases, as the logs periodically cause me to overnight have to purge my log entries and restart rsyslogd. Sep 7 08:00:53 karmic-laptop pulseaudio[32305]: rtp.c: sendmsg() failed: Invalid argument and Sep 7 11:29:36 karmic-laptop pulseaudio[32305]: sap.c: sendmsg() failed: Invalid argument user@karmic-laptop:~$ sudo dpkg -l | grep pulseaudio ii pulseaudio 1:0.9.16~test7-14-g7ca81-0ubuntu1~ubuntuaudiodev1 PulseAudio sound server Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/425857/+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 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
In Bug #1521771, I spent some time tracking down different behavior between the mysql-5.5 "init" and "upstart" scripts. They differ on how many seconds are waited between the SIGTERM and SIGKILL signals are sent. Different values can mean the difference between a slower clean shutdown and a shutdown interrupted by a SIGKILL signal. In the case of that of that package, redirecting the "init.d" calls to the upstart script will have a positive impact in my opinion-- giving more time for MySQL to shutdown cleanly. So the proposed patch will be functionally helpful. I do suggest that for any package that's affected by this, the "init.d" script should be cleaned out, so only the code remains that redirects people to the upstart script. There is nothing about this line of code in an "init.d" script which indicates that that all the code below it is about to ignored: . /lib/lsb/init-functions Nor does the proposed patch emit any output that confirms that redirect is happened. The result is that someone could pull their hair out wondering why the "init.d" script is not behaving as expected. Realize that there are packages like "ec2-consistent-snapshot" which exist only in a PPA and make a hardcoded call to "/etc/init.d/mysql". It does that in hopes of working on non-Debian-based systems as well. (The package is also several years old, from an era when init.d scripts were more common). I'm not sure what small projects are supposed to when they want to issue a command like "stop mysql" in a way that might work across SysV init scripts, upstart and systemd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists Status in lsb package in Ubuntu: Fix Released Status in upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released Status in upstart source package in Utopic: Fix Released Status in upstart package in Debian: New Bug description: [ impact ] Previously, init.d scripts that were replaced by upstart jobs had "upstart-job" symlink as a redirect in-place, which directed users at using upstart commands. Despite the good intentions, that never actually taught people about the correct interfaces. Now with the advent of co-installability of multiple init systems, users may have systemd, upstart, and sysv-init all installed on users system and have init.d scripts / upstart jobs / systemd units all available. To avoid any doubt, we should support executing /etc/init.d/ scripts which may call into upstart, or into systemd, or actually execute the script in question depending on whether there is native configuration for that particular job and which init system we are running under. [ test case ] Invoking init.d script should invoke upstart commands, for example: $ /etc/init.d/ssh status ssh start/running, process 4620 $ /etc/init.d/ssh stop stop: Rejected send message, 1 matched rules; type="method_call", sender=":1.2469694" (uid=1000 pid=3908 comm="stop ssh ") interface="com.ubuntu.Upstart0_6.Job" member="Stop" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init") $ sudo /etc/init.d/ssh stop ssh stop/waiting $ sudo /etc/init.d/ssh start ssh start/running, process 5373 $ sudo /etc/init.d/ssh restart ssh stop/waiting ssh start/running, process 5405 Description:Ubuntu 13.10 Release:13.10 mysql-server-5.5: Installed: 5.5.35-0ubuntu0.13.10.1 Candidate: 5.5.35-0ubuntu0.13.10.1 Version table: *** 5.5.35-0ubuntu0.13.10.1 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ saucy-security/main amd64 Packages 100 /var/lib/dpkg/status 5.5.32-0ubuntu7 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages In Ubuntu 13.10, the Upstart job and the init.d script do not work properly. In previous versions, the init.d script was a symlink to the wrapper script around upstart (/lib/init/upstart-job). This conflict means that if the server was started using the init.d script, upstart does not recognize that the server is running and will attempt to start a second instance of mysqld. Also problematic is that if the upstart job is started using the service or start commands, the init.d script's "stop" function runs a mysql shutdown, but upstart simply restarts mysqld (because it's marked respawn in the upstart config). Description: Ubuntu 14.04 Release: 14.04 mysql: mysql-server-5.5.43-0ubuntu0.14.04.1 The problem in
[Touch-packages] [Bug 1319973] Re: libuuid needs a default shell (seems to not specify any?)
That should nave been nologin. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1319973 Title: libuuid needs a default shell (seems to not specify any?) Status in util-linux package in Ubuntu: Confirmed Status in util-linux source package in Trusty: Confirmed Status in util-linux source package in Utopic: Confirmed Status in util-linux package in Debian: Fix Released Bug description: antarus@killbot:~$ getent passwd libuuid libuuid:x:100:101::/var/lib/libuuid: A missing shell specification means it takes the default shell (usually /bin/sh). DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu Trusty Tahr (development branch) DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 antarus@killbot:/tmp$ apt-cache policy libuuid1 libuuid1: Installed: 2.20.1-5.1ubuntu20 Candidate: 2.20.1-5.1ubuntu20 It should have /usr/sbin/nologin as its shell. -A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1319973/+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 1319973] Re: libuuid needs a default shell (seems to not specify any?)
This remains a potential security issue with Ubuntu 14.04. It appears that the util-linux (2.25-5) should set the login shell as nologin. It seems here we need an update which finds the shells already set as /bin/sh and resets them to nlogin -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1319973 Title: libuuid needs a default shell (seems to not specify any?) Status in util-linux package in Ubuntu: Confirmed Status in util-linux source package in Trusty: Confirmed Status in util-linux source package in Utopic: Confirmed Status in util-linux package in Debian: Fix Released Bug description: antarus@killbot:~$ getent passwd libuuid libuuid:x:100:101::/var/lib/libuuid: A missing shell specification means it takes the default shell (usually /bin/sh). DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu Trusty Tahr (development branch) DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 antarus@killbot:/tmp$ apt-cache policy libuuid1 libuuid1: Installed: 2.20.1-5.1ubuntu20 Candidate: 2.20.1-5.1ubuntu20 It should have /usr/sbin/nologin as its shell. -A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1319973/+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
