[Touch-packages] [Bug 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
Ahyes, that fixes things on Ubuntu/Jammy as well: mkdir -p /etc/apparmor.d/disable # (did not exist, over here) ln -s /etc/apparmor.d/usr.bin.tcpdump /etc/apparmor.d/disable # (note, no sbin, but bin) apparmor_parser -R /etc/apparmor.d # (this is indeed needed, instead of an apparmor restart) -- 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 fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Confirmed Status in lxd package in Ubuntu: Invalid Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd from the host's namespace. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+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 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x
How about this case: - I make a hypothetical package that depends on libxxhash < 0.8 because I want the "broken/old" xxh128 support; - I have libxxhash 0.7.3 (that came with Focal); - I have rsync 3.1.x (that came with Focal); - Now I release-upgrade my system from Focal to Groovy; - I get all kinds of new packages, including rsync 3.2.3; - Dependency resolution fixes that I _don't_ get libxxhash 0.8 _because_ I have: - (a) my hypothetical package pinned and it depends on libxxhash<0.8; - (b) rsync that depends on libxxhash>=0.7.1. - The dependencies are all still satisfied and I get to keep libxxhash=0.7.3. In this new situation I have completed the upgrade to Groovy. As long as my hypothetical package that depends on libxxhash <0.8 exists, Ubuntu will not upgrade libxxhash. And then I'm in the same situation as I am now: root@groovy-rsync:~# apt-mark hold hypothetical-pkg hypothetical-pkg set on hold. root@groovy-rsync:~# apt-cache show hypothetical-pkg | grep ^Depe Depends: libxxhash0 (<= 0.8) root@groovy-rsync:~# apt-get install rsync Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: openssh-server The following NEW packages will be installed: rsync root@groovy-rsync:~# dpkg -l | grep -E 'rsync|libxxhash' hi hypothetical-pkg 1.0 ii libxxhash0:amd64 0.7.3-1 ii rsync3.2.3-2ubuntu1 root@groovy-rsync:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: libxxhash0 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. This may not be the commonest of cases. But this would be an impossible situation if rsync_3.2.3 simply depended on 0.8+ instead of on 0.7.1+. (An impossible situation is good in this case, because you have to choose between either hypothetical-pkg or rsync.) So, I still feel that this is a bug in the rsync control file in Groovy. Not a bug in the rsync source. (Ok, in fact, I think it's ultimately a bug in soname-version/symbol handling of libxxhash. But that's not where the problem manifests itself.) I'll leave it as is if you still feel it should be closed. But at least it has some visibility/presence on the internet so others are helped if they also run into this issue. Cheers :) Walter ** Changed in: rsync (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1934992 Title: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x Status in rsync package in Ubuntu: New Bug description: **Problem** $ rsync root@focal-system:/etc/.pwd.lock . ERROR: .pwd.lock failed verification -- update discarded. rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1816) [generator=3.2.3] $ rsync root@focal-system:/etc/.pwd.lock . --debug=all opening connection using: ssh -l root focal-system rsync --server --sender \ -e.LsfxCIvu . /etc/.pwd.lock (10 args) (Client) Protocol versions: remote=31, negotiated=31 Client negotiated checksum: xxh128 ... **Cause** focal-system# dpkg -l | grep -E 'libxxhash|rsync' ii libxxhash0:amd64 0.7.3-1 amd64 ii rsync 3.2.3-2ubuntu1 amd64 **Why this affects only us and not more people?** On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we need the lz4 compression support we've fetched a newer rsync (from Groovy). However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact it needs 0.8+. **Details** On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from Ubuntu/Groovy because we need the lz4 compression support. focal-system# apt-cache show rsync Package: rsync ... Version: 3.2.3-2ubuntu1 Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15), liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0), libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4) ... Alongside this we had libxxhash0 0.7.3-1 from Focal: focal-system# apt-cache policy libxxhash0 libxxhash0: Installed: 0.7.3-1 Candidate: 0.7.3-1 Version table: *** 0.7.3-1 500 500 http://ARCHIVE/ubuntu focal/universe amd64 Packages 100 /var/lib/dpkg/status According to the dependencies, this should work. But the combination does not, as this quote from the rsync maintainer would tell you: https://github.com/WayneD/rsync/issues/122#issuecomment-737690913 > Yeah, Cyan4973 could have told you that the 128-bit xxhash only > just stabilized in its 0.8.0 release, so anything older than > that isn't compatible. **The fix** As the maintainer points
[Touch-packages] [Bug 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x
Hi Wayne! Thanks for commenting. > It's only the 128-bit hash that depends on 0.8.0. > The 0.7 version works fine with rsync, giving it > the 64-bit and 32-bit hashes. Yes. Except it seems that if you switch the libxxhash0 from 0.8 to 0.7, you get different behaviour. rsync doesn't check what kind of xxh128 is produced, so we end up with a mismatch. Steps to reproduce: wget -q https://launchpad.net/ubuntu/+archive/primary/+files/rsync_3.2.3-2ubuntu1_amd64.deb wget -q https://launchpad.net/ubuntu/+archive/primary/+files/libxxhash0_0.7.3-1_amd64.deb wget -q https://launchpad.net/ubuntu/+archive/primary/+files/libxxhash0_0.8.0-1ubuntu1.20.10.1_amd64.deb focal-node-1: sudo dpkg -i libxxhash0_0.7.3-1_amd64.deb \ rsync_3.2.3-2ubuntu1_amd64.deb touch empty-file.txt echo A > non-empty-file.txt focal-node-2: sudo dpkg -i rsync_3.2.3-2ubuntu1_amd64.deb \ libxxhash0_0.8.0-1ubuntu1.20.10.1_amd64.deb rsync -v --debug=nstr \ focal-node-1:*empty-file.txt \ . Result: Client negotiated checksum: xxh128 empty-file.txt WARNING: empty-file.txt failed verification -- update discarded (will try again). non-empty-file.txt WARNING: non-empty-file.txt failed verification -- update discarded (will try again). empty-file.txt ERROR: empty-file.txt failed verification -- update discarded. non-empty-file.txt ERROR: non-empty-file.txt failed verification -- update discarded. sent 104 bytes received 255 bytes 239.33 bytes/sec total size is 2 speedup is 0.01 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1816) [generator=3.2.3] focal-node-2: $ ls *empty* ls: cannot access '*empty*': No such file or directory I don't mind if I don't get xxh128 and get some poorer hash. But I _do_ mind if I get a hash that produces different results. If I install libxxhash0 0.7.3 on both: things work. If I install libxxhash0 0.8.x on both: things work. But when there is a mismatch, things break. And uselessly too. I ended up syncing lots of GBs multiple times because our job kept retrying. I hope that clarifies the situation. Walter P.S. Alternative solutions could be: - not exporting xxh128 functions from libxxhash0 0.7.3 (but it might be a bit late for that); - checking that xxh128 produces sane values in rsync before choosing that option. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1934992 Title: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x Status in rsync package in Ubuntu: New Bug description: **Problem** $ rsync root@focal-system:/etc/.pwd.lock . ERROR: .pwd.lock failed verification -- update discarded. rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1816) [generator=3.2.3] $ rsync root@focal-system:/etc/.pwd.lock . --debug=all opening connection using: ssh -l root focal-system rsync --server --sender \ -e.LsfxCIvu . /etc/.pwd.lock (10 args) (Client) Protocol versions: remote=31, negotiated=31 Client negotiated checksum: xxh128 ... **Cause** focal-system# dpkg -l | grep -E 'libxxhash|rsync' ii libxxhash0:amd64 0.7.3-1 amd64 ii rsync 3.2.3-2ubuntu1 amd64 **Why this affects only us and not more people?** On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we need the lz4 compression support we've fetched a newer rsync (from Groovy). However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact it needs 0.8+. **Details** On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from Ubuntu/Groovy because we need the lz4 compression support. focal-system# apt-cache show rsync Package: rsync ... Version: 3.2.3-2ubuntu1 Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15), liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0), libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4) ... Alongside this we had libxxhash0 0.7.3-1 from Focal: focal-system# apt-cache policy libxxhash0 libxxhash0: Installed: 0.7.3-1 Candidate: 0.7.3-1 Version table: *** 0.7.3-1 500 500 http://ARCHIVE/ubuntu focal/universe amd64 Packages 100 /var/lib/dpkg/status According to the dependencies, this should work. But the combination does not, as this quote from the rsync maintainer would tell you: https://github.com/WayneD/rsync/issues/122#issuecomment-737690913 > Yeah, Cyan4973 could have told you that the 128-bit xxhash only > just stabilized in its 0.8.0 release, so anything older than > that isn't compatible. **The fix** As the maintainer points out, version 0.7 is not stable (= broken for our intents and purposes) and thus not fit for use with rsync 3.2. I would
[Touch-packages] [Bug 1934992] [NEW] rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x
Public bug reported:
**Problem**
$ rsync root@focal-system:/etc/.pwd.lock .
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1816) [generator=3.2.3]
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
-e.LsfxCIvu . /etc/.pwd.lock (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...
**Cause**
focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii libxxhash0:amd64 0.7.3-1 amd64
ii rsync 3.2.3-2ubuntu1 amd64
**Why this affects only us and not more people?**
On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
need the lz4 compression support we've fetched a newer rsync (from
Groovy).
However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact it
needs 0.8+.
**Details**
On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from
Ubuntu/Groovy because we need the lz4 compression support.
focal-system# apt-cache show rsync
Package: rsync
...
Version: 3.2.3-2ubuntu1
Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4)
...
Alongside this we had libxxhash0 0.7.3-1 from Focal:
focal-system# apt-cache policy libxxhash0
libxxhash0:
Installed: 0.7.3-1
Candidate: 0.7.3-1
Version table:
*** 0.7.3-1 500
500 http://ARCHIVE/ubuntu focal/universe amd64 Packages
100 /var/lib/dpkg/status
According to the dependencies, this should work. But the combination does not,
as this quote from the rsync maintainer would tell you:
https://github.com/WayneD/rsync/issues/122#issuecomment-737690913
> Yeah, Cyan4973 could have told you that the 128-bit xxhash only
> just stabilized in its 0.8.0 release, so anything older than
> that isn't compatible.
**The fix**
As the maintainer points out, version 0.7 is not stable (= broken for
our intents and purposes) and thus not fit for use with rsync 3.2.
I would argue that it's a good idea to bump the dependency of rsync
3.2.3 on Groovy to libxxhash0>=0.8
After all, in Groovy there is a libxxhash0 0.8.0-1ubuntu1.20.10.1, so
that would not be a problem. And it would fix issues for those mixing
and matching packages.
Thanks!
Walter Doekes
OSSO B.V.
(*) possible patch:
$ diff -pu debian/control{.orig,}
--- debian/control.orig 2021-07-08 09:56:57.646861644 +0200
+++ debian/control 2021-07-08 09:57:38.499029903 +0200
@@ -8,7 +8,7 @@ Build-Depends: debhelper-compat (= 13),
libacl1-dev,
libpopt-dev,
liblz4-dev,
- libxxhash-dev,
+ libxxhash-dev (>= 0.8),
libzstd-dev,
zlib1g-dev,
libssl-dev
** Affects: rsync (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1934992
Title:
rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x
Status in rsync package in Ubuntu:
New
Bug description:
**Problem**
$ rsync root@focal-system:/etc/.pwd.lock .
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1816) [generator=3.2.3]
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
-e.LsfxCIvu . /etc/.pwd.lock (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...
**Cause**
focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii libxxhash0:amd64 0.7.3-1 amd64
ii rsync 3.2.3-2ubuntu1 amd64
**Why this affects only us and not more people?**
On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
need the lz4 compression support we've fetched a newer rsync (from
Groovy).
However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact
it needs 0.8+.
**Details**
On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from
Ubuntu/Groovy because we need the lz4 compression support.
focal-system# apt-cache show rsync
Package: rsync
...
Version: 3.2.3-2ubuntu1
Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4)
...
Alongside this we had libxxhash0 0.7.3-1 from Focal:
focal-system# apt-cache policy libxxhash0
libxxhash0:
Installed: 0.7.3-1
Candidate: 0.7.3-1
Version
[Touch-packages] [Bug 1350782] Re: Upstart does not reopen /var/log/upstart/* logfiles upon log rotation
A google search turned up this as the most likely candidate for my
logrotate+gzip issues.
I'm going to try this for a workaround:
/var/log/upstart/*.log {
daily
missingok
rotate 7
compress
notifempty
nocreate
# Added by wjd 2017-03 for launchpad bug #1350782
delaycompress
sharedscripts
postrotate
lsof | awk '/ \/var\/log\/upstart\/.*\.log.+/{print $9}' | sed
-e 's#.*/##;s#\..*##' | xargs -IX service X restart >/dev/null
endscript
}
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1350782
Title:
Upstart does not reopen /var/log/upstart/* logfiles upon log rotation
Status in upstart package in Ubuntu:
Confirmed
Bug description:
Note: this issue is reported from a 12.04 system, but I've confirmed
the same behavior on a 14.04 system.
Logrotate configuration for Upstart logs has no postrotate action:
/var/log/upstart/*.log {
daily
missingok
rotate 7
compress
notifempty
nocreate
}
As a result, when logs are rotated, upstart keeps open handles on
deleted log files instead of reopening the new log files:
# lsof -p1 | fgrep /var/log/upstart
. . .
init 1 root8w REG 253,1 62 789436
/var/log/upstart/dbus.log.1 (deleted)
. . .
From this point on, all subsequent log messages are lost, delivered
into a deleted file.
I could not find a way to get the upstart init process to reopen its
log files, short of restarting _all_ services that log to
/var/log/upstart/*.log files, which does not seem like a good solution
at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: upstart 1.5-0ubuntu7.2
ProcVersionSignature: Ubuntu 3.2.0-60.91-generic 3.2.55
Uname: Linux 3.2.0-60-generic x86_64
ApportVersion: 2.0.1-0ubuntu17.6
Architecture: amd64
Date: Thu Jul 31 10:43:25 2014
InstallationMedia: Ubuntu-Server 10.04.4 LTS "Lucid Lynx" - Release amd64
(20120214.2)
MarkForUpload: True
ProcEnviron:
LC_CTYPE=en_US.UTF-8
TERM=xterm-256color
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: upstart
UpgradeStatus: Upgraded to precise on 2013-10-23 (280 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1350782/+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 1465959] Re: In phones with two SIMs, if you don't unlock SIM1, the message for unlocking SIM2 says "SIM1"
I think so. I did a single attempt at reproducing it recently, I didn't succeed. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-network in Ubuntu. https://bugs.launchpad.net/bugs/1465959 Title: In phones with two SIMs, if you don't unlock SIM1, the message for unlocking SIM2 says "SIM1" Status in indicator-network package in Ubuntu: Fix Released Bug description: How to reproduce: 1. Use a dual-SIM phone (tested on bq Aquaris E4.5) with two SIMs, both SIMs should require a PIN to unlock. 2. When booting the phone and prompted for SIM1 PIN, click on "X" in order not to provide a PIN (thus SIM1 will remain locked). 3. WHAT YOU GET: The message says "Input PIN for SIM1" even if this is the turn for SIM2 to input the PIN. WHAT SHOULD HAVE HAPPENED: The message should say "Input PIN for SIM2" instead, since now we are typing the PIN for SIM2. (I am using a localised build, so the text in the message may not be exact.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1465959/+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 1426307] Re: location is inaccurate
I've never had GPS location work without the HERE functions enabled. As soon as I disable it (I have to restart for a change to take effect) I get *no* location info whatsoever. (I have waited for weeks to get a GPS lock, to no avail.) The SensorsStatus tool tells me (when HERE is enabled) that I only have Horizontal accuracy, and that drifts between 8m and 250m. Location: Netherlands SIMs/network: dual sim and lots of wifi around Version: latest Ubuntu 15.04 r24 (20150713) on the Aquaris BQ 4.5 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to location-service in Ubuntu. https://bugs.launchpad.net/bugs/1426307 Title: location is inaccurate Status in Canonical System Image: Fix Released Status in location-service package in Ubuntu: Fix Released Status in location-service source package in Vivid: Confirmed Status in location-service package in Ubuntu RTM: Fix Released Bug description: current build number: 122 device name: krillin channel: ubuntu-touch/devel-proposed alias: ubuntu-touch/vivid-proposed last update: 2015-02-25 15:06:29 version version: 122 version ubuntu: 20150225 version device: 20150210-95b6a9f version custom: 20150225 Location is inaccurate, it thinks that I'm several kilometres away from my actual location, in the middle of the sea. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: ubuntu-location-service-bin 2.1+15.04.20150126.1-0ubuntu1 Uname: Linux 3.4.67 armv7l ApportVersion: 2.16.1-0ubuntu2 Architecture: armhf Date: Fri Feb 27 11:10:42 2015 InstallationDate: Installed on 2015-02-25 (2 days ago) InstallationMedia: Ubuntu Vivid Vervet (development branch) - armhf (20150225-020204) SourcePackage: location-service UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.init.ubuntu.location.service.conf: 2015-02-10T21:38:59 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1426307/+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 1442105] Re: GPS not working on my BQ Ubuntu Touch
Same here. I had the Using GPS only since I bought the phone and GPS never worked. Days/weeks of uptime should be enough to get a GPS lock, right? Now I enabled the GPS/Wifi/mobile-network (HERE), rebooted, and like you said, within 30 seconds, the SensorsStatus tool started reporting GPS info. Yay. Running latest 15.04 r24 atm (updated 7 july). This does look like a bug which should be fixed; you shouldn't have to enable privacy-sensitive modes to get the GPS to work. I'll go back and try what happens when I disable the HERE location detection again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-location in Ubuntu. https://bugs.launchpad.net/bugs/1442105 Title: GPS not working on my BQ Ubuntu Touch Status in indicator-location package in Ubuntu: Confirmed Bug description: Hi. I tried to use GPS (HERE maps, Google Maps) on my Ubuntu Touch from BQ (I am on update 20), but the app dont detect my location. I have to mention that I check Here terms Condition and GPS and location are checked. I attached some screenshot from what I did. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-location/+bug/1442105/+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 1447502] Re: GPS/location icon in notification top bar is out of sync with settings
No idea; I only noticed this when initially using the phone. If you think it's fixed in the next version, I'll believe you. I'll reopen if it happens again. Thanks! ** Changed in: indicator-location (Ubuntu) Status: New = Fix Released ** Changed in: indicator-location (Ubuntu RTM) Status: New = Fix Released ** Changed in: unity8 (Ubuntu) Status: Opinion = Fix Released ** Changed in: unity8 (Ubuntu RTM) Status: Opinion = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-location in Ubuntu. https://bugs.launchpad.net/bugs/1447502 Title: GPS/location icon in notification top bar is out of sync with settings Status in indicator-location package in Ubuntu: Fix Released Status in unity8 package in Ubuntu: Fix Released Status in indicator-location package in Ubuntu RTM: Fix Released Status in unity8 package in Ubuntu RTM: Fix Released Bug description: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: - even though I've disabled GPS and Location detection, the crosshair icon is always on. - after playing around with *enabling* the GPS and waiting a bit, the icon *disappeared*. and then I found that the icon does stay away when disabling it again. perhaps GPS was on the whole time after all? Further info: - this icon had been on since I got the phone (and restarted at least two times) - I've disabled GPS almost the first thing I did Cheers, Walter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-location/+bug/1447502/+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 1452161] Re: Leaving flight mode, unlocking on dual SIM: header PIN's title prompt does not match with the SIM's number
*** This bug is a duplicate of bug 1447479 *** https://bugs.launchpad.net/bugs/1447479 ** This bug has been marked a duplicate of bug 1447479 SIM Pin1 and Pin2 headings get mixed up sometimes -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-network in Ubuntu. https://bugs.launchpad.net/bugs/1452161 Title: Leaving flight mode, unlocking on dual SIM: header PIN's title prompt does not match with the SIM's number Status in indicator-network package in Ubuntu: Confirmed Bug description: I am on krillin #21 on rtm/stable channel. * I go on flight mode (the checkbox from the indicator becomes green) * I go out flight mode (the checkbox from the indicator is not anymore green) * I have 2 button to unlock the SIM 1 and SIM 2 * I click on unlock SIM 1, I have a screen with the title unlock SIM 2 * I click on unlock SIM 2, I have s screen with the title unlock SIM 1 result: both SIM * title is wrong Since I have the same PIN, I am not sure if the button call to unlock the wrong SIM, on if it's only the wrong title. Edit: New usecase, I hope it is the same bug: I've just unlock by starting to unlock first the SIM2: * I click on unlock SIM 2, I have a screen with the title unlock SIM 2 * I click on unlock SIM 1, I have s screen with the title unlock SIM 2 result: both SIM 2 title (1 wrong, 1 true) Edit2: Same just happend, but with SIM1 in first and both were with SIM 1 title Some details: * Both SIM are from the same operator: Free (mobile.free.fr) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1452161/+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 1447479] Re: SIM Pin1 and Pin2 headings get mixed up sometimes
100% reproducible: - boot with dual sim, - when it says sim 1: press X (to cancel) - then it says sim 1, but it wants sim 2 code - enter sim 2 code - at this point, only sim 2 is activated, - authenticate, go to network, unlock sim 1, now it says sim 2 but wants sim 1 code -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1447479 Title: SIM Pin1 and Pin2 headings get mixed up sometimes Status in indicator-network package in Ubuntu: Confirmed Status in unity8 package in Ubuntu: Confirmed Bug description: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've had the following issue: - both SIMs are inserted, I'm asked to unlock one SIM, and the text above says SIM2 while in fact it wanted the pin code for SIM1 (and vice versa): notably, the counter for the amount of failed attempts was for the correct sim -- which I know, because I didn't have the right code for one of the SIMs the first time I noticed this. - I've also had the problem that the right passphrase didn't unlock (bug #1426876) but returned to the network/mobile screen where I could click un unlock a second time, after which it worked For codes that can only be wrongly entered three times, these mixups are rather severe. Cheers, Walter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1447479/+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 1387207] Re: [greeter] strange persistent Enter SIM1 PIN dialog on Greeter
** Summary changed: - [greeter] strange persistant Enter SIM1 PIN dialog on Greeter + [greeter] strange persistent Enter SIM1 PIN dialog on Greeter -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity-notifications in Ubuntu. https://bugs.launchpad.net/bugs/1387207 Title: [greeter] strange persistent Enter SIM1 PIN dialog on Greeter Status in Ubuntu UX bugs: Fix Committed Status in indicator-network package in Ubuntu: Incomplete Status in unity-notifications package in Ubuntu: Confirmed Status in unity8 package in Ubuntu: Confirmed Status in unity8 package in Ubuntu RTM: New Bug description: Build r133 Krillin I'm not entirely sure how to reproduce this bug but I try to sum up the conditions and how the phone was set up before. 1. Make sure both SIM cards are inserted 2. SIM1 is locked 3. reboot device 4 skip SIM PIN entry When skipping the SIM PIN entry screen, you can see a small glitch on the top of the screen. It looks like a dialog/snap but it disappears very quickly. Now, I had my device locked for a while and when I unlocked it via the hard key button a snap decision appeared on top of the greeter saying Enter SIM PIN1. It is possible to swipe away the greeter screen but then this is it. You are basically stuck. I managed as well to pull down the notifications menu but the snap stayed on top of that. It looks like there is there passcode screen in the background and if you want to return back to the greeter you have to lock/unlock the device with the hard key button. Maybe anyone can reproduce this bug or knows what causes it. Please see attached screenshots for more visual info. Update: 14.04 r269 krillin The glitch of briefly appearing dialog still persists. Every time the device is rebooted and user has to enter the SIM PIN. UX comment- The desired resolution is that users are presented with the actual SIM PIN screen without the appearing glitch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-ux/+bug/1387207/+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 1447482] Re: Notification area is readable/editable while in screen-lock mode
*** This bug is a duplicate of bug 1358340 *** https://bugs.launchpad.net/bugs/1358340 Oops. Hadn't found those. Sorry. Disabling both the Launcher and Notifications and quick settings suits my needs. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1447482 Title: Notification area is readable/editable while in screen-lock mode Status in unity8 package in Ubuntu: New Bug description: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: even though the phone is supposed to be locked, one can: - read incoming messages from the notification (top swipe) area, - change on/off state of bluetooth, gps, wifi, brightness Expected: when not logged in, one should not be able to see more than: - number of notifications (possibly type), but not content - the time, battery life, gps, mobile, bluetooth and wifi *state*, but not be able to switch them on/off Cheers, Walter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1447482/+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 1447502] [NEW] GPS/location icon in notification top bar is out of sync with settings
Public bug reported: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: - even though I've disabled GPS and Location detection, the crosshair icon is always on. - after playing around with *enabling* the GPS and waiting a bit, the icon *disappeared*. and then I found that the icon does stay away when disabling it again. perhaps GPS was on the whole time after all? Further info: - this icon had been on since I got the phone (and restarted at least two times) - I've disabled GPS almost the first thing I did Cheers, Walter ** Affects: unity8 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1447502 Title: GPS/location icon in notification top bar is out of sync with settings Status in unity8 package in Ubuntu: New Bug description: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: - even though I've disabled GPS and Location detection, the crosshair icon is always on. - after playing around with *enabling* the GPS and waiting a bit, the icon *disappeared*. and then I found that the icon does stay away when disabling it again. perhaps GPS was on the whole time after all? Further info: - this icon had been on since I got the phone (and restarted at least two times) - I've disabled GPS almost the first thing I did Cheers, Walter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1447502/+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 1447482] [NEW] Notification area is readable/editable while in screen-lock mode
Public bug reported: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: even though the phone is supposed to be locked, one can: - read incoming messages from the notification (top swipe) area, - change on/off state of bluetooth, gps, wifi, brightness Expected: when not logged in, one should not be able to see more than: - number of notifications (possibly type), but not content - the time, battery life, gps, mobile, bluetooth and wifi *state*, but not be able to switch them on/off Cheers, Walter ** Affects: unity8 (Ubuntu) Importance: Undecided Status: New ** Tags: security ** Tags added: security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1447482 Title: Notification area is readable/editable while in screen-lock mode Status in unity8 package in Ubuntu: New Bug description: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: even though the phone is supposed to be locked, one can: - read incoming messages from the notification (top swipe) area, - change on/off state of bluetooth, gps, wifi, brightness Expected: when not logged in, one should not be able to see more than: - number of notifications (possibly type), but not content - the time, battery life, gps, mobile, bluetooth and wifi *state*, but not be able to switch them on/off Cheers, Walter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1447482/+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 1447499] [NEW] Rotation locked icon in notification top bar icon is counter intuitive
Public bug reported: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: - the Rotation locked icon appears as phone which can be rotated, which is illogical to me. If the rotation is locked, then I'd expect the icon to cross out the rotated phone. Perhaps simply adding a diagonal through the icon would make it better? Thanks, Walter severity=veryverylow ** Affects: unity8 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1447499 Title: Rotation locked icon in notification top bar icon is counter intuitive Status in unity8 package in Ubuntu: New Bug description: On the Aquaris E4.5 (ubuntu 14.10 r21, Utopic Unicorn dev, armhf 20150410-232623), I've noticed the following: - the Rotation locked icon appears as phone which can be rotated, which is illogical to me. If the rotation is locked, then I'd expect the icon to cross out the rotated phone. Perhaps simply adding a diagonal through the icon would make it better? Thanks, Walter severity=veryverylow To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1447499/+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 1031718] Re: Obscure error messages caused by ubuntu patch
So. Apparently this has been fixed somewhere along the road to Ubuntu 14.04. The patch is commented out in the debian/patches/series file in version 1.3.0-0ubuntu2. However, the debian/changelog doesn't tell me when that happened (or when it was added, for that matter). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libjpeg-turbo in Ubuntu. https://bugs.launchpad.net/bugs/1031718 Title: Obscure error messages caused by ubuntu patch Status in “libjpeg-turbo” package in Ubuntu: Confirmed Bug description: Environment: Description:Ubuntu 12.04 LTS Release:12.04 libjpeg-turbo8 1.1.90+svn733-0ubuntu4.1 Ubuntu's own patch (FixLibraryStartup.patch) causes obscure Error opening file for reading: Permission denied error messages. The patch adds some auxv related stuff to the library init that attempt to read /proc/self/auxv. If it fails the above error is printed usually ending up to application's log that's using the library. Looking at the log it's completely unclear where that error came from and what file was it trying to read. The /proc/self/auxv has 0400 permissions and is owned by the user who started the process. If the process drops privileges and setuid()'s to another user, the file is no longer readable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/+bug/1031718/+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 1322843] Re: foregrounding a sudo'd vim will sometimes break terminal state
** Patch added: SUDO-649_Patch-to-ignore-program-generated-SIGTSTP--si_pid.patch https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1322843/+attachment/4186391/+files/SUDO-649_Patch-to-ignore-program-generated-SIGTSTP--si_pid.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1322843 Title: foregrounding a sudo'd vim will sometimes break terminal state Status in sudo: Unknown Status in “sudo” package in Ubuntu: New Bug description: See this bug: http://www.sudo.ws/bugs/show_bug.cgi?id=649 Started on Ubuntu/Trusty since it has a sudo after 1.8.7, (precise has 1.8.3). Steps to reproduce: - take a local machine with a recent sudo (after 1.8.7) - sudo vi - ^Z (control-Z) - fg - repeat ^Z and fg until the fg fails and the screen is partially cleared - now a second fg wil open vim with a broken terminal state: arrow keys will render the escape sequences and other nastiness Fix is provided upstream, but author is currently figuring out why it breaks. Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/sudo/+bug/1322843/+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 1322843] Re: foregrounding a sudo'd vim will sometimes break terminal state
That last patch is the sudo author's fix for the issue. Bug is still open. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1322843 Title: foregrounding a sudo'd vim will sometimes break terminal state Status in sudo: Unknown Status in “sudo” package in Ubuntu: Confirmed Bug description: See this bug: http://www.sudo.ws/bugs/show_bug.cgi?id=649 Started on Ubuntu/Trusty since it has a sudo after 1.8.7, (precise has 1.8.3). Steps to reproduce: - take a local machine with a recent sudo (after 1.8.7) - sudo vi - ^Z (control-Z) - fg - repeat ^Z and fg until the fg fails and the screen is partially cleared - now a second fg wil open vim with a broken terminal state: arrow keys will render the escape sequences and other nastiness Fix is provided upstream, but author is currently figuring out why it breaks. Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/sudo/+bug/1322843/+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 406397] Re: init: job stuck with expect fork/daemon when parent reaps child
Nice tip MarcS. That is indeed better than the other workarounds.
Here, a quick script -- cleanup-upstart.sh -- that checks initctl list
for stalled processes and kills them:
#!/bin/sh
# vim: set ts=8 sw=4 sts=4 et ai tw=71:
upstart_spawn_and_stop() {
name=$1
pid=$2
pkill -xf 'sleep 11' echo killed old sleep process
echo $((pid-2)) |
sudo tee /proc/sys/kernel/ns_last_pid /dev/null
sh -c 'sleep 11 '
sleeppid=`pgrep -xf 'sleep 11'`
if test $sleeppid != $pid; then
echo looks like we did not get the right pid..
return 1
fi
parentpid=`ps -o%P -p$pid | sed -e1d`
if test $parentpid -eq 1; then
echo very well.. we've got a live pid
else
echo looks like it got the wrong parent.. started from X?
return 1
fi
return 0
}
pkill -xf 'sleep 11' echo killed old sleep process
initctl list | tac | while read line; do
procpid=`echo $line | awk '{print $4}'`
if ! test -d /proc/$procpid; then
procname=`echo $line | awk '{print $1}'`
echo $procname:
if upstart_spawn_and_stop $procname $procpid; then
initctl status $name
initctl stop $name # Terminated?
fi
fi
done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
Status in Upstart:
Triaged
Status in “upstart” package in Ubuntu:
Invalid
Status in “upstart” package in Debian:
Confirmed
Status in PLD Linux Distribution:
New
Bug description:
Hi
Wrong use of the expect fork stanza can create job with status
job stop/killled, process nnn
without any process nnn running on the system.
As an example the following avahi.conf should have used
expect daemon, but will instead create a stuck job.
stop on stopping dbus-system
respawn
expect fork
exec avahi-daemon -D
/Emil Renner Berthing
To manage notifications about this bug go to:
https://bugs.launchpad.net/upstart/+bug/406397/+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 406397] Re: init: job stuck with expect fork/daemon when parent reaps child
And I'm happy to say that things are moving to systemd. My cron.conf now looks #44 just so cron gets the right locale in 14.04. I'm baffled that that's the best I can come up with with upstart. If there is a better way, please enlighten me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/406397 Title: init: job stuck with expect fork/daemon when parent reaps child Status in Upstart: Triaged Status in “upstart” package in Ubuntu: Invalid Status in “upstart” package in Debian: Confirmed Status in PLD Linux Distribution: New Bug description: Hi Wrong use of the expect fork stanza can create job with status job stop/killled, process nnn without any process nnn running on the system. As an example the following avahi.conf should have used expect daemon, but will instead create a stuck job. stop on stopping dbus-system respawn expect fork exec avahi-daemon -D /Emil Renner Berthing To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/406397/+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
