There's a detail in the github issue that wasn't noted here:
I have Ubuntu Server 22.04.2 running in a VM (VMWare 13.0.2) on an Apple
Silicon Mac running macOS 13.4.
That makes the network driver situation less likely but the firewall
situation still possible.
A few extra questions:
What kind of
If the primary issue is that other devices can only resolve your
hostname after restarting avahi-daemon for a short time, plus, this
machine doesn't see anything else on the network, it means that for one
reason or another mDNS packets on port 5353 are not making it back to
this host.
The overwhel
The above analysis is true for SSH, but, I realise it's different for
the PTY passed in by lxc exec.
So my analysis is true maybe, but I am going to move this SSH fix over
to Bug #1667016 so this bug can stay open for the general PTY/buffering
issue.
There is a gap in my explanation of: It's not
** Changed in: apparmor (Ubuntu)
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1641236
Title:
Confined processes inside container can
** Changed in: tcpdump (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1641236
Title:
Confined processes inside container cannot
Note: This affects SSH as well.. not only lxc exec. There is a currently
marked duplicate bug about the SSH part in Bug #1667016
This still persits on focal now. To workaround this for me I have to
*both* use tcpdump with -l (line buffered mode) *and* pipe the output to
cat. You also want to redir
This happens now on Jammy (22.04) on 64-bit (not on 32-bit due to system
limits)
systemd ships a default /usr/lib/sysctl.d/50-pid-max.conf, as per upstream
commit here:
https://github.com/systemd/systemd/pull/12226
** Changed in: procps (Ubuntu)
Status: New => Fix Released
--
You recei
Where is the discussion happening?
I ran the same benchmarks for my i7-6770HQ 4-core system. This really
needs revising.
While disk space using in /boot is a concern, in this example at least
-10 would use only 8MB (10%) more space and cut the time taken from 2m1s
to 13s.
zstd.0 84M 0m2.150s
zst
Most shells (including bash, zsh) have a built-in for kill so it's done
internally. Some shells don't so it executes /bin/kill instead which has
this issue.
One comment noted this was fixed at some point in 2013 in version 3.3.4
but it apparently broke again at some point and is broken at least in
Thanks for the data. I can see you queried 'steven-ubuntu.local' and
that looks like the hostname of the local machine. Can you also query
the hostname of the AFP server you are trying to connect to (using both
getent hosts and avahi-resolve-host-name).
--
You received this bug notification becau
As a side note, it may be time to switch to a new protocol. As even
Apple has dropped support for sharing AFP versions in the last few
releases and is deprecating it's usage. You can use Samba to do SMBFS
including the extra special apple stuff if you need timemachine support
etc on your NAS
--
Y
To assist with this can you get the following outputs from the broken
system:
# Change 'hostname.local' to the hostname expected to work
cat /etc/nsswitch.conf
systemctl status avahi-daemon
journalctl -u avahi-daemon --boot
avahi-resolve-host-name hostname.local
getent hosts hostname.local
*
Subscribing Marc as he seems to be largely maintaining this and made the
original changes and has been keeping the delta. Hopefully he can
provide some insight.
Seems this is a delta to Debian that is being kept intentionally for a
long time, it's frequently in the changelog even in the most recen
Just noticed this today, it's still the same on Ubuntu 20.04. The
default sudoers file ships the admin group having sudo privileges but
the group doesn't exist by default.
While it doesn't have out of the box security implications, I think this
is a security concern as someone could potentially ad
** Changed in: ubuntu-keyring (Ubuntu)
Importance: Undecided => Critical
** Changed in: ubuntu-keyring (Ubuntu)
Importance: Critical => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-keyring in Ubuntu.
http
Updated the following wiki pages:
https://wiki.ubuntu.com/Debug%20Symbol%20Packages
https://wiki.ubuntu.com/DebuggingProgramCrash
With the note:
Note: The GPG key expired on 2021-03-21 and may need updating by either
upgrading the ubuntu-dbgsym-keyring package or re-running the apt-key command.
Just to make the current status clear from what I can gather:
- The GPG key was extended by 1 year to 2022-03-21
- On Ubuntu Bionic (18.04) and newer the GPG key is normally installed
by the ubuntu-dbgsym-keyring package (on 18.04 Bionic onwards). This
package is not yet updated. An update to thi
Right, the systems are running 1.1ubuntu1.18.04.11 - in my original
query to you I was trying to figure out if the patches in .12 or .13
were likely to have caused this specific situation and you weren't sure
hence the bug report with more details.
** Changed in: unattended-upgrades (Ubuntu)
** Attachment added: "unattended-upgrades-dpkg.log.4"
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1893889/+attachment/5406808/+files/unattended-upgrades-dpkg.log.4
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is s
** Attachment added: "dpkg_-l"
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1893889/+attachment/5406810/+files/dpkg_-l
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
ht
Uploaded all historical log files in lp1893889-logs.tar.gz
Uploaded dpkg_-l
For convenient access also uploaded unattended-upgrades.log.4,
unattended-upgrades-dpkg.log.4 and dpkg.log.6 which have the lines from
the first instance of hitting the error
--
You received this bug notification becaus
** Attachment added: "dpkg.log.6"
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1893889/+attachment/5406809/+files/dpkg.log.6
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubun
** Attachment added: "unattended-upgrades.log.4"
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1893889/+attachment/5406807/+files/unattended-upgrades.log.4
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
** Attachment added: "all unattended-upgrades and dpkg logs"
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1893889/+attachment/5406806/+files/lp1893889-logs.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is sub
Public bug reported:
unattended-upgrades attempted to upgrade nova from 2:17.0.9-0ubuntu1 to
2:17.0.10-0ubuntu2.1 (bionic-security), however nova-common contains a
modified conffile (/etc/nova/nova.conf) which prompts during upgrade and
leaves apt/dpkg in a permanent error state requiring manual
i
This is fixed in Ubuntu 20.04 with nss-mdns 0.14 and later which does
proper split horizon handling.
** Changed in: avahi (Ubuntu)
Status: Triaged => Fix Released
** Changed in: nss-mdns (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you a
I'm not sure it makes sense to just universally skip "tun*" interfaces
(at least yet) but we may need to review the scenarios in which
/etc/network/if-up.d/avahi-autoipd is executing.
Helio: Can you provider a reproducer scenario? e.g. is this ubuntu
server, ubuntu desktop, what is the contents of
OK thanks for the updates. So I can see a lot of mDNS packets in the
lp1874021.pcap capture from various sources. I can see some printers,
google cast, sonoff, etc. Curiously though when you do the avahi cache
dump it isn't seeing any of these.
Wireshark is showing malformed packets for many of th
Looking at jctl.txt things look normal, the server starts up, gets
server startup complete and then adds the appropriate IP for wlan0.
Config file looks normal.
Can you please try the following to collect extra debug info
(1) Start a tcpdump and leaving it running - tcpdump --no-promiscuous-mode
For anyone looking at this in 2020, this is fixed in nss-mdns 0.14 which
is in Ubuntu Focal 20.04 - it will now correctly pass through unicast
.local lookups.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
ht
For focal we should actually remove this script, since nss-mdns
automatically performs this behaviour and doesn't rely on the "hack" of
stopping avahi-daemon to prevent resolution of .local domains via DNS.
If this error is serious we could consider backport to stable releases.
--
You received t
(for clarity nss-mdns 0.14 does this behavior itself automatically, in
0.10 in bionic does not)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1870824
Title:
Errors in scrip
The bug was marked invalid for *Avahi* but Confirmed for network-manager
-- because the bug exists not in Avahi (it simply logs the message you
see as a result of the IP address being removed). So the bug is still
valid and confirmed, just for network-manager instead.
--
You received this bug not
When I say bind, I actually meant to bind the outgoing connection from
Pidgin (not related to Avahi). So when creating the socket, specify the
source IP address.
The problem is that when you connect (without specifying a source) then
at least for IPv6 due to the routing table specification of the
Part of the reason this behavior exists in Avahi is that many
applications do not correctly retrieve the scope ID (interface index)
when doing hostname resolution, and if not supplied then connection to
such a link local address will fail. Applications are likely to receive
such an address at rando
The most likely cause for this is that you have packets outbound on port
5353 firewalled either locally or on your network device. When another
host pings the address, the responses are sent via multicast and Avahi
caches that response, and so can then use it without having to transmit
a packet.
U
This is a bug in CUPS ultimately, it's driving Avahi using the D-BUS API
(as opposed to manual service files in /etc/avahi/services, this is only
really used for a sysadmin to manually add services, most other types of
advertisements such as printers are expected to use the API to advertise
it).
M
Hi Markos,
After creating this service file, if you check the contents of
/var/log/syslog, you will see that Avahi gave an error parsing the file:
May 10 16:01:30 optane avahi-daemon[1260]: Loading service file
/services/test.service.
May 10 16:01:30 optane avahi-daemon[1260]: /services/test.ser
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
** Changed in: avahi (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
Potential upstream fix for backport, may be relevant to MAAS:
https://github.com/lathiat/avahi/pull/206
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1752737
Title:
[2.3.0-
On the previously mentioned HP server today I was able to get closer to
reproducing the situation by testing with bionic (4.15.0-47-generic)
instead of xenial (4.4)
On bionic, unlike xenial, even with the BIOS set to "BIOS controlled
dynamic" mode, the intel_pstate driver is loaded instead of pcc-
This is a bug in CUPS, CUPS needs to remember the address family of the
advertised service (and preferably the interface ID). Avahi does know
this interface and does provide it in the API responses to CUPS, but
it's currently not using it.
For more detailed information please refer to here:
https:
Confirmed that pcc-cpufreq *can* be used in preference to intel_pstate
even on a CPU that supports intel_pstate if the firmware tables are
setup to request such. One such server is an E5-2630 v3 HP DL360 G9
(shuckle).
On the default "dynamic" firmware setting you get driver=pcc-cpufreq +
governor=
Something I was not previously aware of that informs this a bit more, is
that in some BIOS modes (apparently HP uses this extensively, unsure
about Dell and others) you get a "Collaborative Power Control" mode,
which sets the scaling_driver to pcc-cpufreq (as opposed to cpufreq) and
is some weird h
(as context to this information, apparently this particularly bad
performance experienced with 'powersave' happens when the BIOS power
control is set to the default, and goes away when in the BIOS you set
power management to 'os control' - so there is some additional
information needed to determine
Forgot to comment: This issue was resolved by the Mirror team shortly
after
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1814105
Title:
random 404s on security.ubuntu.com
reproduction
(4) Can you give me a full run down of the steps to get into this state, e.g.
the machine was deployed with a specific Ubuntu ISO and then the full list of
commands used to that time, etc.
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
** Changed in: av
Marking invalid as it's not technically a bug against avahi, but as
above, have arranged to have the issue looked at.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1814105
Ti
I was able to reproduce this issue, I have forwarded it onto the
relevant team to look into.
** Changed in: avahi (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https:/
** Changed in: avahi (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/652870
Title:
Avahi update causes internet connetions to fail
Sta
** Bug watch added: github.com/lathiat/avahi/issues #2
https://github.com/lathiat/avahi/issues/2
** Also affects: avahi via
https://github.com/lathiat/avahi/issues/2
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch
** Changed in: avahi (Ubuntu)
Status: Incomplete => Triaged
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
** Bug watch added: github.com/lathiat/avahi/issues #210
https://github.com/lathiat/avahi/issues/210
** Also affects: avahi via
** Bug watch added: github.com/apple/cups/issues #5438
https://github.com/apple/cups/issues/5438
** Also affects: cups via
https://github.com/apple/cups/issues/5438
Importance: Unknown
Status: Unknown
** Description changed:
When using CUPS filters, these filters can take a few
I enabled "debug2" log level and tested again. I found the following entries in
the log:
d [20/Nov/2018:08:22:25 +0100] cupsdCheckJobs: 1 active jobs, sleeping=0,
ac-power=-1, reload=0, curtime=1542698545
d [20/Nov/2018:08:22:25 +0100] cupsdCheckJobs: Job 75 - dest="hvitcpdf",
printer=(nil), sta
Public bug reported:
When using CUPS filters, these filters can take a few seconds to
complete.
In this case no documents are allowed to be lost on printing failures,
so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
14.04.
With cups on 18.04, you get the following message in
Instructions fixed to work with the 80 column limit of comments:
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe
multiverse" | \
sudo tee -a /etc/apt/sources.list.d/ddebs.list
sudo apt update
sudo apt install linux-tools-generic ubuntu-dbgsym-keyring \
linux-cloud-
Hi Matt,
Thanks for the report. I'd like to profile avahi using perf to get
information on what functions are being executed. Could you run the
following commands to generate such data?
If you are unsure about any of this feel free to ask.
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) ma
Hi Nim (nimpetro),
You've added a comment to an existing bug, which dopes not appear to be
related to the problem you are having. This bug is about network issues
with CUPS connecting to printers and not related to the page print
formatting being incorrect.
Please either open a new bug for your i
Looks like the recent astroid rebuild/changes removed the file, but it's
still present in alembic
** Changed in: alembic (Ubuntu)
Importance: Critical => High
** Changed in: astroid (Ubuntu)
Importance: Critical => High
** Changed in: dh-python (Ubuntu)
Importance: Critical => High
**
Public bug reported:
Python packages should not ship /usr/lib/python3/dist-
packages/.pytest_cache
Recently, two packages python3-alembic and python3-astroid both shipped
these files which collided on package install
dh-python has been improved upstream to stream all hidden "dot"
directories in
It appears these packages are in main but mainly pulled in (at least on
my system) by 'devscripts'. This affects cosmic.
** Also affects: alembic (Ubuntu)
Importance: Undecided
Status: New
** Also affects: astroid (Ubuntu)
Importance: Undecided
Status: New
** Changed in: astr
igh
** Changed in: avahi (Ubuntu Bionic)
Assignee: (unassigned) => Trent Lloyd (lathiat)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1752411
Title:
bind9-host, avah
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1752411
Title:
bind9-host, avahi-daemon-ch
> When host call fails (even with timeout), it returns "1" claiming
"dns_has_local()=true".
0 = true, 1 = false (you implied the opposite)
What may add confusion here is the grep -vq check is like an extra check
to make sure host didn't return 0 (success = we found .local) but then
say 'not found
I agree with the sentiment that 5 seconds feels too long, however as a
workaround I decided I would just copy the existing timeout. I certainly
would not want to make it longer since this is in the critical boot
path.
I would generally agree that in general a DNS request should fail faster
however
** Patch added: "lp1752411-avahi-host-timeout-cosmic.patch"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5178710/+files/lp1752411-avahi-host-timeout-cosmic.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which i
** Description changed:
+ [Impact]
+
+ * Network connections for some users fail (in some cases a direct
+ interface, in others when connecting a VPN) because the 'host' command
+ to check for .local in DNS called by /usr/lib/avahi/avahi-daemon-check-
+ dns.sh never times out like it should - le
Request sponsorship of this upload for cosmic and then SRU to bionic
- New debdiff uploaded for both bionic and cosmic
- Fixed the SRU version for bionic
- Added a comment about the workaround to the script
- Updated bug description with SRU template
Tested patch working on bionic with my mach
** Patch added: "lp1752411-avahi-host-timeout-bionic.patch"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5178693/+files/lp1752411-avahi-host-timeout-bionic.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which i
** Patch added: "lp1752411-avahi-host-timeout-cosmic.patch"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5178692/+files/lp1752411-avahi-host-timeout-cosmic.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which i
Hoping to get attention to this again. Since 18.04.1 is out now, more
and more users are likely to hit this issue as more users will be
upgrading. This issue applies equally to desktop and server scenarios.
I would like to get lp1752411-avahi-host-timeout.diff sponsored for
upload please
--
You
** Attachment added: "netplan config"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783272/+attachment/5167024/+files/01-netcfg.yaml
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs
** Attachment added: "syslog"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783272/+attachment/5167022/+files/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/b
** Attachment added: "log of terminal session during upgrade"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783272/+attachment/5167023/+files/apt-upgrade-console-log.txt
** Description changed:
Upgrading the systemd package, which contains systemd-networkd, appears
to restart ne
Public bug reported:
Upgrading the systemd package, which contains systemd-networkd, appears
to restart networkd and subsequently reconfigure network interfaces
causing a brief connectivity outage.
This is a bionic system which has a network bridge as it's primary
interface through netplan.
You
** Changed in: avahi (Ubuntu)
Status: Confirmed => Invalid
--
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/1586528
Title:
Avahi-daemon withdraws address reco
Sponsors: Can we get this debdiff uploaded now? We've had a few more
reports and I'd like to get this workaround in place.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/175241
Thanks for the note ronny, that is a really helpful note. That may well
be the cause for many of these cases.
--
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/1586528
I'd still like to get the upload debdiff for 'timeout' that I prepared
uploaded. Even if we manage to debug the bind9-host issue, it will
still be useful to have the timeout command there as a backup. Not long
before we run out of time for bionic release.
I am actively looking at the bind9-host
There is a new bind9 upload to bionic-proposed (9.11.3+dfsg-1ubuntu1)
Tested with this version and 'host' is still hanging. So this fix is
still required.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
http
Not sure how this happened,, strange dpkg issue it seems like FS
corruption or shutdown during a package install. Unusual to see that.
To get your system back on track, I suggest you try some combination of
these commands (You might need to run each a couple of times depending)
sudo dpkg --confi
** Patch added: "lp1752411-avahi-host-timeout.diff"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5117372/+files/lp1752411-avahi-host-timeout.diff
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
--
You rece
With host -d I simply get
> Trying "local"
When it works normally I get;
Trying "local"
Host local. not found: 3(NXDOMAIN)
Received 98 bytes from 10.48.134.6#53 in 1 ms
Received 98 bytes from 10.48.134.6#53 in 1 ms
The system I am hitting this issue on is an upgraded system (rather than
a fresh
FYI this will not effect DHCP as the hostname change is only used for
mDNS and is not used as the system hostname and thus would affect DHCP
etc
The cause of this is knwon and hopefully a fix will get done for it
soon.. basically its when IP addresses are added then removed too fast.
Can also happ
Looking at your logs, generally it seems like dbus is broken for some
reason.
Would also be great to check it's status:
# systemctl status dbus
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.lau
Thanks for the report.
How did this happen, was it during a package upgrade for a normal
installation or is this a new install, etc. If a new install, describe
which install media download and options you used. Or were you
installing avahi-daemon or some other package using apt install, etc.
--
I did some testing using strace and looking at backtraces of why "host"
is stuck, and it's not immediately clear to me why it's getting stuck.
Will need to look more in depth into it tracing it's actual execution -
it's multi threaded and using poll so not super straight forward from
the trace for
If you are hit by this issue, it seems sufficient to simply ask dpkg to
finish configuration as it seems the prerm script isn't retried
$ dpkg --configure -a
Or you can just re-run your upgrade command (e.g. "apt upgrade") which
should do the same plus finish any upgrades that didn't finish (whic
Analysis here appears related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768620
Seems the interactions here are quite complex
To reproduce the problem, you can do on xenial:
(install old version)
# apt install avahi-daemon=0.6.32~rc+dfsg-1ubuntu2
avahi-dnsconfd=0.6.32~rc+dfsg-1ubuntu2 av
** Patch added: "gdb-bionic-gcore-bash.debdiff"
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1762320/+attachment/5107574/+files/gdb-bionic-gcore-bash.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubu
Public bug reported:
gcore fails to execute on bionic
$ gcore
/usr/bin/gcore: 28: /usr/bin/gcore: Syntax error: "(" unexpected
Line 28 is:
28 dump_all_cmds=()
This appears to be bash syntax for arrays (as reinforced further down)
No VPN in use.. this is probably a bug equally in bind9-host and avahi-
daemon
The host shouldn't be getting stuck and avahi should probably make the
script timeout somehow
** Also affects: bind9 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: bind9 (Ubuntu)
Importance: U
This seems to be some kind of weird interaction with systemd
activation...
root@optane:/lib/systemd# systemctl stop avahi-daemon.socket
Job for avahi-daemon.socket canceled.
I think basically the issue is the service is immediately started again
due to activation.. i'm not sure why avahi-dnsconfd
@jecs Thanks for the feedback; I am curious.. how many service do you
have on your network?
If you run "avahi-browse -a -t|wc -l" -- how many lines do you have?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
This bug was fixed in the package avahi for trusty, xenial and artful.
bionic is not affected by this issue.
xenial: 0.6.32~rc+dfsg-1ubuntu2.1
trusty: 0.6.31-4ubuntu1.2
Would be great if the various people affected by this could confirm they
no longer hit the issue.
** Changed in: avahi (Ubuntu)
Sure thing!
I conducted two tests based on the reproduction steps in the SRU
template
* setup lxd (apt install lxd, lxd init, get working networking)
* lxc launch ubuntu:16.04 avahi-test --config security.privileged=true
* lxc exec avahi-test sudo apt install avahi-daemon
For xenial, artful v
Verification completed on trusty, xenial and artful
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1661869
Title:
maas install fails inside of a 16.04 lxd container due to a
** Tags removed: verification-needed-artful verification-needed-trusty
verification-needed-xenial
** Tags added: verification-done-artful verification-done-trusty
verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is su
Yeah the exact same change in the 0.7 release (rlimit section removal)
that is shipping in Bionic fixes the issue there, and the issue isn't
present in Bionic.
I also individually tested each of the trusty/xenial/artful packages
built from the supplied debdiffs to ensure the issue goes away after
Trusty is technically not directly affected by the container proc issue
as there was an Ubuntu patch dropped in xenial to skip setting rlimit-
nproc when /run/container_type=lxc
Could happen if that doesn't exist though, and the memory issue can
still occur, so still recommend upload.
** Descript
1 - 100 of 164 matches
Mail list logo
