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
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
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
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
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
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
*
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
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
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
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
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
** 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
** 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
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
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
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.
** 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
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
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=
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
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
** 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
** 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/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
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
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
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
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
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
** 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
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:/
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
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
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
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
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
** 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
** 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
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
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
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)
@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 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
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
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)
** 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
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
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
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
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.
--
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
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
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
** 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
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
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
I’ll follow up on this tomorrow and see what I need to get it pushed
through.
On Sun, 4 Mar 2018 at 9:50 pm, TJ wrote:
> In IRC support we've been getting reports about this issue for 17.10;
> Can we get the SRU pushed out?
>
> --
> You received this bug notification because you are a member of
Public bug reported:
evolution-source-registry is using 100% CPU after login and never stops,
it continues to do so after kill/respawn or reboot. This started
sometime after upgrade to bionic and has been consistent for the last
couple of weeks.
Looking at the process with perf, it seems that it
Public bug reported:
/etc/pam.d/systemd-user does not currently call pam_keyinit.so -- it's
possible this should instead be added to common-session-noninteractive
but I am not entirely sure about that - someone with more understanding
of the PAM modules would probably need to weigh in on that. In
Found a Debian bug about the same issue but with AFS instead of fscrypt:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846377
** Bug watch added: Debian Bug tracker #846377
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846377
--
You received this bug notification because you are a mem
** Changed in: avahi (Ubuntu)
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/1638345
Title:
avahi-daemon cras
** Description changed:
- The bug, and workaround, are clearly described in this mailing list
- thread:
+ [Original Description]
+ The bug, and workaround, are clearly described in this mailing list thread:
https://lists.linuxcontainers.org/pipermail/lxc-
users/2016-January/010791.html
** Patch added: "lp1661869-artful.debdiff"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1661869/+attachment/5079949/+files/lp1661869-artful.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
h
** Patch added: "lp1661869-xenial.debdiff"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1661869/+attachment/5079950/+files/lp1661869-xenial.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
h
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
** Patch added: "lp1661869-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1661869/+attachment/5079951/+files/lp1661869-trusty.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
h
I have updated Bug #1661869 with an SRU template and new updates to fix
this issue, plus the issue in that bug.
The fix is simply to update /etc/avahi/avahi-daemon.conf and comment out
the entire [rlimits] section. You can do this yourself (but the package
update will do it for you).
It'd be gre
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
** 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
** 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-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
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
> 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
** 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
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
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
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
**
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
** 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
** 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
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
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
This is known upstream but not yet solved, working on it I have a theory
** Changed in: avahi (Ubuntu)
Status: New => Confirmed
** Bug watch added: github.com/lathiat/avahi/issues #41
https://github.com/lathiat/avahi/issues/41
--
You received this bug notification because you are a me
https://github.com/lathiat/avahi/issues/41
--
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/1698248
Title:
avahi-daemon constantly registers/withdraws IPv6 address record
Sta
*** This bug is a duplicate of bug 1668559 ***
https://bugs.launchpad.net/bugs/1668559
Commenting here as the duplicate parent is Private at the moment.
Main issue is here, hitting rlimit-data which is set by default in the config
file to 4M
> kernel: mmap: avahi-daemon (992): VmData 4272128
New binutils upload today of 2.29, which conflicts with linux-tools as
it turns out it Depends binutils (>= 2.28), binutils (<< 2.29)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.n
Same problem with the new 4.11.0-12 upload, i'm assuming since binutils
is still in -proposed it wasn't built against?
linux-tools-4.11.0-12 : Depends: binutils (< 2.29) but 2.29-2ubuntu1 is
to be installed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded pa
This is resolved now.
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1702056
Title:
perf broken on
Avahi starts fine in a 16.04 container for me. Can you share what
errors you are actually seeing Dustin?
lxc launch ubuntu:16.04 xenial
ssh ubuntu@
sudo apt install avahi-daemon
sudo systemctl status avahi-daemon
The post you linked is from January 2016 and on 15.10 (wily).. it does in fact
no
Oh right, I see now.. too early to comment as usual :(
The problem is that you are setting up a "privileged" container for MAAS
which does not use UID mapping, hence the issue shows up in the MAAS
workflow but not with a normal container deployment.
The rlimit-nproc is simply set in /etc/avahi/a
There was previously a patch to skip setting this (because it would
fail), it was removed for a couple of reasons including an upstream
change not to abort of setting RLIMIT_NPROC failed:
I've committed a change upstream to simply remove the default setting of this
option, and will prepare a debd
** Changed in: avahi (Ubuntu)
Status: New => Confirmed
** Changed in: avahi (Ubuntu)
Importance: Undecided => High
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
--
You received this bug notification because you are a member of Ubuntu
Tou
1 - 100 of 164 matches
Mail list logo
