Bug#905277: gdm3: GDM blocks SIGUSR1 from being used by PAM scripts

[Dariusz Gadomski]

Package: gdm3
Version: 3.28.2-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

In case of the following scenario:
1. PAM configured to run auth and session with pam_exec scripts synchronizing
   via SIGUSR1
2. Using GDM as the login manager causes SIGUSR1 never reaches the target
   scripts.

Workaround:
Use SIGUSR2 in the scripts.
Comment out block_sigusr1() call in daemon/main.c.

In Ubuntu, the attached patch was applied to unblock SIGUSR1 before PAM comes
to action.

  * Unblock SIGUSR1 before PAM. (LP: #1782152)

This issue has been fixed upstream:
https://gitlab.gnome.org/GNOME/gdm/issues/399

Thanks for considering the patch.
Dariusz Gadomski

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-29-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gdm3-3.28.2/debian/control gdm3-3.28.2/debian/control
--- gdm3-3.28.2/debian/control  2018-06-13 13:56:13.0 +0200
+++ gdm3-3.28.2/debian/control  2018-07-23 10:58:27.0 +0200
@@ -5,8 +5,7 @@
 Source: gdm3
 Section: gnome
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian GNOME Maintainers 

+Maintainer: Debian GNOME Maintainers 

 Uploaders: Iain Lane , Jeremy Bicha , 
Laurent Bigonville , Michael Biebl , Tim 
Lunn 
 Build-Depends: gnome-pkg-tools (>= 0.16.3),
debhelper (>= 10.3),
diff -Nru gdm3-3.28.2/debian/control.in gdm3-3.28.2/debian/control.in
--- gdm3-3.28.2/debian/control.in   2018-06-13 13:56:13.0 +0200
+++ gdm3-3.28.2/debian/control.in   2018-07-23 10:58:27.0 +0200
@@ -1,8 +1,7 @@
 Source: gdm3
 Section: gnome
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian GNOME Maintainers 

+Maintainer: Debian GNOME Maintainers 

 Uploaders: @GNOME_TEAM@
 Build-Depends: gnome-pkg-tools (>= 0.16.3),
debhelper (>= 10.3),
diff -Nru gdm3-3.28.2/debian/patches/series gdm3-3.28.2/debian/patches/series
--- gdm3-3.28.2/debian/patches/series   2018-06-13 13:56:13.0 +0200
+++ gdm3-3.28.2/debian/patches/series   2018-07-23 10:58:27.0 +0200
@@ -25,3 +25,4 @@
 ubuntu_config_error_dialog.patch
 ubuntu_dont_set_language_env.patch
 ubuntu_prefer_ubuntu_session_fallback.patch
+unblock-sigusr1.patch
diff -Nru gdm3-3.28.2/debian/patches/unblock-sigusr1.patch 
gdm3-3.28.2/debian/patches/unblock-sigusr1.patch
--- gdm3-3.28.2/debian/patches/unblock-sigusr1.patch1970-01-01 
01:00:00.0 +0100
+++ gdm3-3.28.2/debian/patches/unblock-sigusr1.patch2018-07-23 
10:58:27.0 +0200
@@ -0,0 +1,71 @@
+Description: session-worker: unblock SIGUSR1 before PAM
+ Right now we unblock SIGUSR1 just before starting
+ the session, but we should really do it before
+ starting the worker/PAM.
+
+ This commit fixes that and removes a useless call
+ to set SIGUSR1 back to the default disposition,
+ right before exec (which does the same thing anyway)
+ .
+ gdm3 (3.28.2-3ubuntu2) cosmic; urgency=medium
+ .
+   * Unblock SIGUSR1 before PAM. (LP: #1782152)
+
+Origin: upstream, 
https://gitlab.gnome.org/GNOME/gdm/commit/b0d1ca9ebf605abb63b95ef73d56d56a1109002e
+Bug: https://gitlab.gnome.org/GNOME/gdm/issues/399
+Bug-Ubuntu: https://gitlab.gnome.org/GNOME/gdm/issues/399
+Last-Update: 2018-07-23
+
+--- gdm3-3.28.2.orig/daemon/gdm-session-worker-job.c
 gdm3-3.28.2/daemon/gdm-session-worker-job.c
+@@ -117,12 +117,19 @@ session_worker_job_setup_journal_fds (vo
+ static void
+ session_worker_job_child_setup (GdmSessionWorkerJob *session_worker_job)
+ {
++sigset_t mask;
+ session_worker_job_setup_journal_fds ();
+ 
+ /* Terminate the process when the parent dies */
+ #ifdef HAVE_SYS_PRCTL_H
+ prctl (PR_SET_PDEATHSIG, SIGTERM);
+ #endif
++/*
++ * Reset signal mask to default since it was altered by the
++ * manager process
++ */
++sigemptyset ();
++sigprocmask (SIG_SETMASK, , NULL);
+ }
+ 
+ static void
+--- gdm3-3.28.2.orig/daemon/gdm-session-worker.c
 gdm3-3.28.2/daemon/gdm-session-worker.c
+@@ -2025,8 +2025,6 @@ gdm_session_worker_start_session (GdmSes
+ char  *home_dir;
+ intstdin_fd = -1, stdout_fd = -1, stderr_fd = -1;
+ gboolean has_journald = FALSE, needs_controlling_terminal = 
FALSE;
+-sigset_t mask;
+-
+ /* Leak the TTY into the session as stdin so that it stays 
open
+  * witho

Bug#900005: hwdata pnp.ids contains outdated data for LG

[Dariusz Gadomski]

Package: hwdata
Version: 0.290-1
Severity: minor

Dear Maintainer,

hwdata pnp.ids content is outdated compared to what's upstream. For instance
GSM is still resolved as Goldstar despite that name not being in use since
1995.

This leads to a confusing situation like displaying 'Goldstar' in Gnome
settings after connecting a fairly new display/TV.

I'd appreciate syncing with upstream.

Thank you,
Dariusz Gadomski

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic-proposed'), (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-22-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hwdata depends on:
ii  pciutils  1:3.5.2-1ubuntu1
ii  usbutils  1:007-4build1

hwdata recommends no packages.

hwdata suggests no packages.

-- no debconf information

Bug#889884: open-vm-tools: Misleading tools.conf template shipped with the package

[Dariusz Gadomski]

Hi Bernd,

Thanks for taking care of this.

> good catch, will be shipped with the next upload.
Btw. could you give me any estimate about when the next upload may
take place?

Ideally, if it happens before March 1 (according to [1]) it would be
automatically imported to Ubuntu as well.

[1]: https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule

Thanks,
Dariusz

Bug#889884: open-vm-tools: Misleading tools.conf template shipped with the package

[Dariusz Gadomski]

This is an alternative I recommend (based on the comment from
open-vm-tools/lib/include/vmware/tools/log.h)

 tools.conf 
[logging]
# Turns on logging globally. It can still be disabled for each domain.
# log = true

# Disables core dumps on fatal errors; they're enabled by default.
# enableCoreDump = false

# Defines the "vmsvc" domain, logging to file
# vmsvc.level = message
vmsvc.handler = file
# Setup file rotation - keep 3 files
vmsvc.maxOldLogFiles = 3
# Max log file size kept: 1 MB
vmsvc.maxLogSize = 1

# Defines the "vmtoolsd" domain, and disable logging for it.
# vmtoolsd.level = none
 end of tools.conf 

Thanks for looking into this.

Bug#889884: open-vm-tools: Misleading tools.conf template shipped with the package

[Dariusz Gadomski]

Source: open-vm-tools
Version: 2:10.2.0-2
Severity: normal

Dear Maintainer,

The tools.conf template shipped with the Debian package 
(debian/local/tools.conf) is incorrect.

It's current contents:
bindir = "/usr/bin"
do not mean anything to open-vm-tools - it's not interpreted in any way by 
vmtoolsd.

Moreover, on the first launch this content is cleared by a piece of code doing 
a "config upgrade".

I believe replacing it with a more meaningful content is necessary.

Bug#883863: sysstat: another potential segfault while running sadc

[Dariusz Gadomski]

Package: sysstat
Version: 11.6.0-1
Followup-For: Bug #883863
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


*** /tmp/tmpNGiBTg/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

Ubuntu decided to use the full upstream patch for this issue (including
patching the read_filesystem function in rd_stats.c.

  * Add 15-yet-another-mtab-reading-fix.patch to handle another case of
unsafe mtab reading. (LP: #1720627)


Thanks for considering the patch.
diff -Nru sysstat-11.6.0/debian/control sysstat-11.6.0/debian/control
--- sysstat-11.6.0/debian/control   2017-11-16 10:43:50.0 +0100
+++ sysstat-11.6.0/debian/control   2017-12-06 16:29:31.0 +0100
@@ -1,8 +1,7 @@
 Source: sysstat
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Robert Luberda 
+Maintainer: Robert Luberda 
 Build-Depends: debhelper (>= 10), gettext, libsensors4-dev, pkg-config
 Standards-Version: 4.1.0
 Homepage: http://pagesperso-orange.fr/sebastien.godard/
diff -Nru sysstat-11.6.0/debian/patches/15-yet-another-mtab-reading-fix.patch 
sysstat-11.6.0/debian/patches/15-yet-another-mtab-reading-fix.patch
--- sysstat-11.6.0/debian/patches/15-yet-another-mtab-reading-fix.patch 
1970-01-01 01:00:00.0 +0100
+++ sysstat-11.6.0/debian/patches/15-yet-another-mtab-reading-fix.patch 
2017-12-06 16:29:31.0 +0100
@@ -0,0 +1,91 @@
+Description: Handle segmantation fault while reading /etc/mtab
+ A segmentation fault may happen with "sadc -S DISK..." or
+ "sadc -S XDISK..." when lines longer than 512 bytes are read from
+ /etc/mtab.
+ 
+ Such lines are possible for instance when overlay2 filesystem
+ with docker is used. In such a case a single mtab entry can look
+ like this (note that new line characters were added for readability,
+ the original entry contained only one '\n' at the end):
+ 
+ overlay /var/lib/docker/overlay2/f23d2377a67b9ab1b49555ecd09b2ccdc03
+ 7e0ee5d9e54f87e59f07f4398e71f/merged overlay rw,relatime,lowerdir=/v
+ ar/lib/docker/overlay2/l/L6VKIYXWBQSJ5R7V35SS43R6Y6:/var/lib/docker/
+ overlay2/l/UCCHKGXUJPWCMLHR36IZJNNIQP:/var/lib/docker/overlay2/l/RKV
+ YEXD2FH65FTMK76RDWPLESX:/var/lib/docker/overlay2/l/DX4JZRKTFP2GOO4V6
+ OWQ6CPJFY:/var/lib/docker/overlay2/l/6CYNWDKADUPPDZJ5IHOH2R7Y5S:/var
+ /lib/docker/overlay2/l/JTPINUZIATXADL6XWFHG2OYGSF:/var/lib/docker/ov
+ erlay2/l/OTSTIV5TTRHF4IUD7BODQ2FUON:/var/lib/docker/overlay2/l/QFNH3
+ EFS5EZGRTC4DPHU3PJ4TU:/var/lib/docker/overlay2/l/ZOOUKT2E5U4CSLP57Z7
+ MXYX5CD:/var/lib/docker/overlay2/l/3LUU6IDR2HWPTVBARC5K6XSMRC:/var/l
+ ib/docker/overlay2/l/XOHYBP4RWXQKQZ43I7JKG24KE4:/var/lib/docker/over
+ lay2/l/MN5M5B7AY5LPXQQC6V2MBJWWBF:/var/lib/docker/overlay2/l/3DRMKQ3
+ 4AIZD2AROU3TVK3OCUT:/var/lib/docker/overlay2/l/73ZXDHBV6C53Q3SPXA57E
+ OLGHU:/var/lib/docker/overlay2/l/C2IZBQ55EUTGEAAORSLE73ZPNM:/var/lib
+ /docker/overlay2/l/ITHARNV7RPWN5S3BCZ2QDMZIMJ:/var/lib/docker/overla
+ y2/l/TQKUV4LEG4AFUUCMFHHRLDBHAH:/var/lib/docker/overlay2/l/N75JZWPPD
+ EKJ4DTN4GMEGTDIZL:/var/lib/docker/overlay2/l/QGUUYAETPMK643DG3AKWJAI
+ IZA,upperdir=/var/lib/docker/overlay2/f23d2377a67b9ab1b49555ecd09b2c
+ cdc037e0ee5d9e54f87e59f07f4398e71f/diff,workdir=/var/lib/docker/over
+ lay2/f23d2377a67b9ab1b49555ecd09b2ccdc037e0ee5d9e54f87e59f07f4398e71
+ f/work 0 0
+ 
+ The crash occurs in the get_filesystem_nr() and read_filesystem()
+ functions which call strchr(line, ' ') but fail to check if the result
+ is not NULL.
+ 
+ This patch adds this check, and when a single mtab entry requires more
+ that one call to fgets() (i.e. the entry is longer than 512 bytes), it
+ ignores outcome of the second and following calls.
+ .
+ sysstat (11.6.0-1ubuntu2) bionic; urgency=medium
+ .
+   * Add 15-yet-another-mtab-reading-fix.patch to handle another case of
+ unsafe mtab reading. (LP: #1720627)
+Origin: upstream, 
https://github.com/sysstat/sysstat/commit/d40c8ecc530303d7e802617f21a9ac85dbcd68bd
+Bug-Ubuntu: https://launchpad.net/bugs/1720627
+Last-Update: 2017-12-06
+
+--- sysstat-11.6.0.orig/rd_stats.c
 sysstat-11.6.0/rd_stats.c
+@@ -2097,7 +2097,8 @@ void read_filesystem(struct stats_filesy
+ {
+   FILE *fp;
+   char line[512], fs_name[128], mountp[256];
+-  int fs = 0;
++  int fs = 0, skip = 0, skip_next = 0;
++  char *pos = 0;
+   struct stats_filesystem *st_filesystem_i;
+   struct statvfs buf;
+ 
+@@ -2105,7 +2106,21 @@ void read_filesystem(struct stats_filesy
+   return;
+ 
+   while ((fgets(line, 

Bug#883863: sysstat: another potential segfault while running sadc

[Dariusz Gadomski]

Source: sysstat
Version: 11.6.0-1
Severity: normal

Dear Maintainer,

This is related to bug #872926. The patch applied to the original bug
contains only half of the upstream fix: get_filesystem_nr in count.c, while
the upstream also considered it's worth to patch the other potential source
of a segfault with long lines: read_filesystem() from rd_stats.c.

I'm not sure how likely it is to run into the other segfault, but for the
sake of keeping consistent with upstream and maintaining safer code
I believe the other part should also be applied to Debian.

Thanks!

Bug#871254: Info received (pcp missing autopkgtests and debian/watch)

[Dariusz Gadomski]

Hello Ken.

Thank you for looking into this issue. I fully agree with the approach
to reuse as much of the existing QA infrastructure as possible.

> I am unfamiliar with autopkgtests, could you please describe:
> - the goals of autopkgtests (specifically what level of testing confidence is 
> aimed for)

The slightly different purpose of the autopkgtests is the reason for me
making the effort of providing the additional tests.
Autopkgtests are intented to be a suite of rather light-weight
integration/acceptance level tests rather than functionality tests.
Their goal is usually to smoke-test the system integration pieces
after any changes done to the packaging (including the software dependencies),
init script management, security policies.
Hence, one of the tests provided checks if e.g. pmcd has been started
correctly, no default firewall policies prevent it from being accessed
(including those introduced in the future) etc.

> - the environment it runs in (post build, with all PCP packages installed?)

It runs in a clean, minimal environment - usually in a VM or a container.
I'm not sure how does it look in Debian, but in case of
Ubuntu it is run every time a Stable Release Update is being prepared for
release to the -proposed pocket. Only packages listed as 'Depends:' in
debian/tests/control are installed on top of the minimal environment.
A clean environment is used for every 'Test:' listed in the control
file, so ideally they should not depend on each other.

> - the way it is invoked and the results it must pass back

The test scripts are run as a non-root user with debian/tests set as CWD. They
are considered successful as long as nothing is written to stderr and return 0.
There are some configuration options changing this behaviour (more info at [1]).

> I'll bet a thin wrapper between the autopkgtests test harness and the 
> existing PCP QA infrastructure will more than match the requirements and keep 
> the test maintenance effort with the upstream PCP development community.

I believe it would a a good idea to include the sanity group as an additional
step of autopkgtests. Moreover, I have already done some tests in that area.
Sadly, I noticed that the test 354 fails consistently while running
in a lxd container with lxd exec  /bin/bash. Running on metal or
in a KVM seems to be perfectly fine).
Looks like its result depends on pipe fd numbering assingned by the system
which seems to differ slightly in this case (please check the attached diff).

Thanks,
Dariusz

[1] 
http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst
PMDA probe: pminfo -h pcp1 -f sample.milliseconds
PMDA probe: pminfo -h pcp1 -f sampledso.milliseconds
PMDA probe: pminfo -h pcp1 -f simple.numfetch
_change_config: Error: cannot change config "pmcd on"
354 - output mismatch (see 354.out.bad)
21c21
< f_config: NULL f_ipc: 6 pid: pmlogger-pid-1 status: -1
---
> f_config: NULL f_ipc: 7 pid: pmlogger-pid-1 status: -1
24c24
< f_config: NULL f_ipc: 7 pid: pmlogger-pid-2 status: -1
---
> f_config: NULL f_ipc: 8 pid: pmlogger-pid-2 status: -1
27c27
< f_config: NULL f_ipc: 8 pid: pmlogger-pid-3 status: -1
---
> f_config: NULL f_ipc: 10 pid: pmlogger-pid-3 status: -1
30c30
< f_config: NULL f_ipc: 9 pid: pmlogger-pid-4 status: -1
---
> f_config: NULL f_ipc: 11 pid: pmlogger-pid-4 status: -1
72c72
< ps: pmlogger-pid-2 pmlogger -x 6 -h localhost
---
> ps: pmlogger-pid-2 pmlogger -x 7 -h localhost
208c208
< f_config: NULL f_ipc: 7 pid: pmlogger-pid-1 status: -1
---
> f_config: NULL f_ipc: 8 pid: pmlogger-pid-1 status: -1
211c211
< f_config: NULL f_ipc: 8 pid: pmlogger-pid-2 status: -1
---
> f_config: NULL f_ipc: 10 pid: pmlogger-pid-2 status: -1
214c214
< f_config: NULL f_ipc: 9 pid: pmlogger-pid-3 status: -1
---
> f_config: NULL f_ipc: 11 pid: pmlogger-pid-3 status: -1
217c217
< f_config: NULL f_ipc: 10 pid: pmlogger-pid-4 status: -1
---
> f_config: NULL f_ipc: 12 pid: pmlogger-pid-4 status: -1
259c259
< ps: pmlogger-pid-2 pmlogger -x 7 -h localhost
---
> ps: pmlogger-pid-2 pmlogger -x 8 -h localhost

Check local PMCD is still alive ...
PMDA probe: pminfo -h pcp1 -f sample.milliseconds
PMDA probe: pminfo -h pcp1 -f sampledso.milliseconds
PMDA probe: pminfo -h pcp1 -f simple.numfetch
Failures: 354
Failed 1 of 1 tests

Bug#871254: pcp missing autopkgtests and debian/watch

[Dariusz Gadomski]

Adding patch proposal.
diff -Nru pcp-3.12.0/debian/changelog pcp-3.12.0/debian/changelog
--- pcp-3.12.0/debian/changelog 2017-06-30 02:30:27.0 +0200
+++ pcp-3.12.0/debian/changelog 2017-08-03 10:37:04.0 +0200
@@ -1,3 +1,9 @@
+pcp (3.12.0-1) unstable; urgency=medium
+
+  * Added autopkgtests and d/watch. (closes: #871254)
+
+ -- Dariusz Gadomski <dariusz.gadom...@canonical.com>  Thu, 03 Aug 2017 
10:37:04 +0200
+
 pcp (3.12.0) unstable; urgency=low
 
   * New release (full details in CHANGELOG).
diff -Nru pcp-3.12.0/debian/tests/check_cli_tools.py 
pcp-3.12.0/debian/tests/check_cli_tools.py
--- pcp-3.12.0/debian/tests/check_cli_tools.py  1970-01-01 01:00:00.0 
+0100
+++ pcp-3.12.0/debian/tests/check_cli_tools.py  2017-08-03 10:37:04.0 
+0200
@@ -0,0 +1,42 @@
+#!/usr/bin/env python3
+
+
+import unittest
+import subprocess
+
+
+class TestCliTools(unittest.TestCase):
+def test_pmerr(self):
+subprocess.check_call(['pmerr', '-2']);
+
+def test_pminfo(self):
+subprocess.check_call(['pminfo', 'proc.nprocs'])
+
+def test_pcp(self):
+subprocess.check_call(['pcp'])
+
+def test_pmstat(self):
+subprocess.check_call(['pmstat', '-s', '1'])
+
+def test_pmdate(self):
+subprocess.check_call(['pmdate', '-7d', '%d%m%Y'])
+
+def test_pmprobe(self):
+subprocess.check_call(['pmprobe'])
+
+def test_pmclient(self):
+subprocess.check_call(['pmclient', '-s', '1'])
+
+def test_pmval(self):
+subprocess.check_call(['pmval', 'proc.nprocs', '-s', '1'])
+
+def test_pmcollectl(self):
+subprocess.check_call(['pmcollectl', '-c', '1'])
+
+def test_pmiostat(self):
+subprocess.check_call(['pmiostat', '-s', '2'])
+
+if __name__ == "__main__":
+import sys
+unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout,
+ verbosity=2))
diff -Nru pcp-3.12.0/debian/tests/check_daemons.py 
pcp-3.12.0/debian/tests/check_daemons.py
--- pcp-3.12.0/debian/tests/check_daemons.py1970-01-01 01:00:00.0 
+0100
+++ pcp-3.12.0/debian/tests/check_daemons.py2017-08-03 10:37:04.0 
+0200
@@ -0,0 +1,70 @@
+#!/usr/bin/env python3
+
+
+import subprocess
+import unittest
+
+
+SERVICE_PMCD = "pmcd.service"
+SERVICE_PMLOGGER = "pmcd.service"
+
+
+PORTS_PMCD = [44321]
+PORTS_PMLOGGER = [4330]
+
+
+PROP_ACTIVESTATE = "ActiveState"
+PROP_SUBSTATE = "SubState"
+STATE_RUNNING = "running"
+STATE_ACTIVE = "active"
+
+
+def format_args(service, property):
+return ["systemctl", "show", "-p" + property, service]
+
+
+def search_output(output, startsWith):
+for line in output.splitlines():
+if line.startswith(startsWith + "="):
+return line[(len(startsWith)+1):]
+
+
+def check_port(port):
+import socket
+s = socket.socket()
+address = '127.0.0.1'
+try:
+s.connect((address, port))
+except:
+return False
+finally:
+s.close()
+return True
+
+
+
+class TestDaemons(unittest.TestCase):
+def check_property(self, service, property, expected):
+output = subprocess.check_output(
+format_args(service, property)).decode("utf-8")
+self.assertEqual(search_output(output, property), expected)
+
+def test_pmcd(self):
+self.check_property(SERVICE_PMCD, PROP_ACTIVESTATE, STATE_ACTIVE)
+self.check_property(SERVICE_PMCD, PROP_SUBSTATE, STATE_RUNNING)
+
+for port in PORTS_PMCD:
+self.assertTrue(check_port(port))
+
+def test_pmlogger(self):
+self.check_property(SERVICE_PMLOGGER, PROP_ACTIVESTATE, STATE_ACTIVE)
+self.check_property(SERVICE_PMLOGGER, PROP_SUBSTATE, STATE_RUNNING)
+
+for port in PORTS_PMLOGGER:
+self.assertTrue(check_port(port))
+
+
+if __name__ == "__main__":
+import sys
+unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout,
+ verbosity=2))
diff -Nru pcp-3.12.0/debian/tests/control pcp-3.12.0/debian/tests/control
--- pcp-3.12.0/debian/tests/control 1970-01-01 01:00:00.0 +0100
+++ pcp-3.12.0/debian/tests/control 2017-08-03 10:37:04.0 +0200
@@ -0,0 +1,5 @@
+Tests: check_daemons.py
+Depends: pcp, dbus
+
+Tests: check_cli_tools.py
+Depends: pcp
diff -Nru pcp-3.12.0/debian/watch pcp-3.12.0/debian/watch
--- pcp-3.12.0/debian/watch 1970-01-01 01:00:00.0 +0100
+++ pcp-3.12.0/debian/watch 2017-08-03 10:37:04.0 +0200
@@ -0,0 +1,3 @@
+version=3
+opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/pcp-$1\.tar\.gz/ \
+  https://github.com/performancecopilot/pcp/tags .*/v?(\d\S+)\.tar\.gz

Bug#871254: pcp missing autopkgtests and debian/watch

[Dariusz Gadomski]

Package: pcp
Version: 3.12.0

There is an effort ongoing to make pcp included in the main component
of the Ubuntu 17.10 release (this may be tracked at [1]).
As a part of this effort we want to improve the quality of the
packaging by integrating autopkgtest and debian/watch file for this
package.

Please consider integrating the proposed patch into Debian packaging.

[1] http://bugs.launchpad.net/bugs/1700827

Bug#847366: gtk apps die with 'Couldn't open libGL.so.1'

[Dariusz Gadomski]

I have added prepared and checked that it actually fixes this issue.
diff -Nru gtk+3.0-3.22.6/debian/changelog gtk+3.0-3.22.6/debian/changelog
--- gtk+3.0-3.22.6/debian/changelog 2017-01-09 15:55:17.0 +0100
+++ gtk+3.0-3.22.6/debian/changelog 2017-01-17 11:19:18.0 +0100
@@ -1,3 +1,9 @@
+gtk+3.0 (3.22.6-2) unstable; urgency=medium
+
+  * Add libgl1 to dependencies. (Closes: #847366)
+
+ -- Dariusz Gadomski <dariusz.gadom...@canonical.com>  Tue, 17 Jan 2017 
11:19:18 +0100
+
 gtk+3.0 (3.22.6-1) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff -Nru gtk+3.0-3.22.6/debian/control gtk+3.0-3.22.6/debian/control
--- gtk+3.0-3.22.6/debian/control   2017-01-09 15:55:17.0 +0100
+++ gtk+3.0-3.22.6/debian/control   2017-01-17 11:19:18.0 +0100
@@ -67,7 +67,8 @@
  ${shlibs:Depends},
  hicolor-icon-theme,
  adwaita-icon-theme,
- shared-mime-info
+ shared-mime-info,
+ libgl1
 Provides: gtk3-binver-3.0.0
 Recommends: libgtk-3-bin
 Suggests: librsvg2-common,

Bug#847366: gtk apps die with 'Couldn't open libGL.so.1'

[Dariusz Gadomski]

On Fri, Dec 09, 2016 at 05:44:16PM +, D. B. wrote:
> #2 seems like the superior option, right?

I agree, yes.

If there is no need of re-enabling gl in cairo then #2 is the best way to go
since GTK+ calls it directly.

Bug#847366: gtk apps die with 'Couldn't open libGL.so.1'

[Dariusz Gadomski]

Looks like this behaviour was introduced with a change to cairo
in version 1.12.16-4 [1]. So looks like gtk was depending on being
linked to libGL.so indirectly via cairo.

So, any of the below should fix it:
1) Re-enable GL/EGL support in cairo.
2) Add libgl1-mesa-glx as a dependency of gtk.
3) [upstream] Introduce runtime checks before calling GL functions.

[1] 
https://anonscm.debian.org/cgit/collab-maint/cairo.git/commit/?id=a4bad9f8463d3e1ed2ebe15890c5c52c1c29a271

Bug#847366: gtk apps die with 'Couldn't open libGL.so.1'

[Dariusz Gadomski]

Package: libgtk-3-0
Version: 3.22.4-1
Severity: normal

Trying to run a gtk-based application that does not depend directly or
indirectly on libgl1-mesa-glx leads to a process termination with
message:
Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No
such file or directory 

I was able to reproduce it with the following apps: gtk3-demo, firefox,
mousetweaks.

Steps to reproduce:
1. Use a headless Debian installation (it is important libgl1-mesa-glx
is not pulled in by the desktop environment etc.). I used a cloud image
from [1].
2. Install the gtk app you want to try:
apt install gtk-3-examples
(notice that libgl1-mesa-glx is not pulled in as a dependency).
3. Login with ssh -X to this Debian machine from a Windows with X server
(e.g. with cywgin with X) or Mac OS X.
4. Run the app:
gtk3-demo

Expected result:
App starts.

Actual result:
Process terminates, message "Couldn't open libGL.so.1: libGL.so.1: cannot open
shared object file: No such file or directory".

I noticed that this is caused by the fact that glXQueryExtension
function gets called without any linking to a GL library.
Looks like gtk should either:
1) Depend on a GL implementation, so apt pulls in the dependency on install.
2) Use a runtime check before calling this function to see if GL is available.

Note: for some reason it is NOT REPRODUCIBLE using a Linux desktop as a remote
client.  In such configuration the control skips the problematic piece of code
as get_cached_gl_visuals (gdk/x11/gdkglcontext-x11.c:1194) returns non-zero
value, so gdk_x11_screen_init_gl call never happens. I suspect this is somehow
related to the fact that I had GL already initialized on my remote desktop.

[1] http://cdimage.debian.org/cdimage/openstack/testing/

Full backtrace below:
#0  gdk_x11_screen_init_gl (screen=screen@entry=0x5594c0d0) at 
././gdk/x11/gdkglcontext-x11.c:859
#1  0x77240c1a in _gdk_x11_screen_update_visuals_for_gl 
(screen=screen@entry=0x5594c0d0)
at ././gdk/x11/gdkglcontext-x11.c:1210
#2  0x772497e6 in _gdk_x11_screen_init_visuals 
(screen=screen@entry=0x5594c0d0)
at ././gdk/x11/gdkvisual-x11.c:309
#3  0x77246856 in _gdk_x11_screen_new 
(display=display@entry=0x55946050, screen_number=0)
at ././gdk/x11/gdkscreen-x11.c:908
#4  0x77236768 in _gdk_x11_display_open (display_name=) 
at ././gdk/x11/gdkdisplay-x11.c:1416
#5  0x7720b1b5 in gdk_display_manager_open_display (manager=, name=0x0)
at ././gdk/gdkdisplaymanager.c:472
#6  0x776fa78a in gtk_init_check (argc=, argv=) at ././gtk/gtkmain.c:1082
#7  0x776fa7b9 in gtk_init (argc=argc@entry=0x0, argv=argv@entry=0x0) 
at ././gtk/gtkmain.c:1139
#8  0x775dc68a in gtk_application_startup 
(g_application=0x559251a0) at ././gtk/gtkapplication.c:293
#9  0x7359ef75 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x735b095c in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x735b9bcc in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x735b9faf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x76451ae2 in g_application_register () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#14 0x7645230f in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#15 0x76452672 in g_application_run () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#16 0x5557285e in main ()

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme  3.22.0-1
ii  hicolor-icon-theme  0.15-1
ii  libatk-bridge2.0-0  2.22.0-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-7
ii  libcairo-gobject2   1.14.6-1.1
ii  libcairo2   1.14.6-1.1
ii  libcolord2  1.3.3-2
ii  libcups22.2.1-2
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.2-2
ii  libgtk-3-common 3.22.4-1
ii  libjson-glib-1.0-0  1.2.2-1
ii  libpango-1.0-0  1.40.3-3
ii  libpangocairo-1.0-0 1.40.3-3
ii  libpangoft2-1.0-0   1.40.3-3
ii  librest-0.7-0   

Bug#753755: Patch proposal to fix the race condition

[Dariusz Gadomski]

On Tue, Jun 30, 2015 at 10:19:08PM +0200, Guus Sliepen wrote:
 Yes I did, and it doesn't work correctly yet. So I'm planning to make it
 so when it tries to ifup a VLAN interface, it first tries to lock the
 physical interface it wants to create a VLAN on. I haven't finished that
 yet, but I'll commit it soon.

Hello Guus, can I help you with this feature in any way? I have a test
environment already set up, so I can at least do extra testing or
review the change if you wish.

Thanks!
Dariusz


signature.asc
Description: Digital signature

Bug#753755: Patch proposal to fix the race condition

[Dariusz Gadomski]

On Tue, Jun 30, 2015 at 10:19:08PM +0200, Guus Sliepen wrote:
 Yes I did, and it doesn't work correctly yet. So I'm planning to make it
 so when it tries to ifup a VLAN interface, it first tries to lock the
 physical interface it wants to create a VLAN on. I haven't finished that
 yet, but I'll commit it soon.

Thank you Guus.

I have quickly refactored my implementation to replace the numerical
group values with a per-interface depending-interfaces stanza, but
since you are fixing the cause for this maybe it will not be
necessary. At least I can't come up with other (beside bonding +
vlans) scenarios that can make use of it.

Maybe you have any other problems not covered by current
implementation that could be solved with it?

Thanks,
Dariusz


signature.asc
Description: Digital signature

Bug#753755: Patch proposal to fix the race condition

[Dariusz Gadomski]

Hello Guus!

On Tue, Jun 16, 2015 at 03:40:04PM +0200, Guus Sliepen wrote:
 Hm, looking at the code I don't think so, since a VLAN interface still
 runs ip link set dev bondX up, which may mess with the
 if-pre-up.d/ifenslave script. I'll do some tests with the concurrency
 branch and VLANs on bonded interfaces to see how well that copes with
 it.

Did you manage to perform the tests to test how VLANs play together
with the allow-bond0 stanza?

I will appreciate any info.

Thanks,
Dariusz


signature.asc
Description: Digital signature

Bug#753755: Patch proposal to fix the race condition

[Dariusz Gadomski]

On Tue, Jun 16, 2015 at 03:40:04PM +0200, Guus Sliepen wrote:
 But is it just ifup iface1..N running in parallel, or is there also an
 ifup -a running at the same time?

According to my observations there is a single ifup iface call for
each interface and additionally there is a ifup -a called from another
script.
 
   [per-interface lockfiles]
  
  Is this implementation for detecting deadlocks available anywhere for
  examination? The mechanism I implemented takes care of deadlocks by
  enforcing consistent order of interface locking and disables further
  locking in recurrent ifupdown invocations with an env variable.
 
 The implementation can be found in the ifupdown git repository:
 
 https://anonscm.debian.org/git/collab-maint/ifupdown.git
 
 Checkout the concurrency branch. Note that it only detects deadlocks
 when one outer invocation of ifup or ifdown recursively calls itself
 (ie, ifup A - ifup B - ifup A). It does not handle the situation when
 two simultaneous invocations on different interfaces recursively call
 eachother (ie, ifup A - ifup B at the same time as ifup B - ifup A).
 But it does do proper locking of an interface for the whole time it is
 being configured, unlike the older versions of ifupdown which really
 allowed two simultaneous invocations of ifup A to be run.

Thank you, I will take a look at the code.

 Hm, looking at the code I don't think so, since a VLAN interface still
 runs ip link set dev bondX up, which may mess with the
 if-pre-up.d/ifenslave script. I'll do some tests with the concurrency
 branch and VLANs on bonded interfaces to see how well that copes with
 it.

I will appreciate sharing the results of your tests.
 
 -- 
 Met vriendelijke groet / with kind regards,
   Guus Sliepen g...@debian.org

Thanks!
Dariusz


signature.asc
Description: Digital signature

Bug#753755: Patch proposal to fix the race condition

[Dariusz Gadomski]

On Tue, Jun 09, 2015 at 06:27:37PM +0200, Guus Sliepen wrote:
 Hi, I just adopted ifupdown from Andrew Shadura. Incidentally I'm also
 the ifenslave maintainer :)

Hello Guus, good luck with maintaining ifupdown :)

The outline for this change is the way the interfaces are handled by
upstart in Ubuntu. They are all brought up in parallel by independent
processes, so there was a need for a universal mechanism to ensure the
proper order of initialization in more complex scenarios.

 
 It is of course not so nice to have to specify those groups by hand,
 especially to assign numbers to them. It would be nicer to just have a
 statement you can put in an interface stanza that tells you which
 interfaces are depending on it, like:
 
 iface bond0 inet static
   depending-interfaces eth0 eth1
 
 This could then implicitly generate the same groups as you have to
 specify explicitly in your case.

I agree with that, it will surely be more user-friendly and will make
/e/n/interfaces easier to read.

 Even better would be to have the race condition be dealt with without
 any changes to /e/n/interfaces. One issue is of course that the
 /r/n/ifstate file is only locked to update the state, and there is no
 state indicating that an interface is in the process of being
 configured. So indeed, a per-interface lockfile should be used, which
 will be locked for the whole duration the interface is being
 (de)configured. Something like /r/n/ifstate-bond0, which is locked using
 fcntl(), and into which the process holding the lock will write the
 state (up/down). To prevent deadlocks (scripts calling ifup/ifdown
 recursively), environment variables are set to indicate which interfaces
 are being configured, like IFUPDOWN_bond0=up, and before trying to lock
 the per-interface lockfile, presence of this environment variable is
 checked. I already have an implementation of the deadlock detection, but
 not yet of per-interface lockfiles.

Is this implementation for detecting deadlocks available anywhere for
examination? The mechanism I implemented takes care of deadlocks by
enforcing consistent order of interface locking and disables further
locking in recurrent ifupdown invocations with an env variable.
 
 But in the case of bonding, there is already a mechanism in place that
 can prevent conflicts between ifup -a and ifup bond0 running
 simultaneously. If you write /e/n/interfaces like this:
 
 allow-bond0 eth0
 iface eth0 inet manual
  bond-master bond0
 
 allow-bond0 eth1
 iface eth1 inet manual
  bond-master bond0
 
 auto bond0
 iface bond0 inet dhcp
  bond-slaves eth0 eth1
  ...
 
 Note that I replaced auto with allow-bond0 for the Ethernet
 interfaces. This causes ifup -a to skip those interfaces, but instead
 will cause ifup bond0 to run ifup eth0 and eth1.

Is this allow-bond0 stanza also going to work with e.g. vlans launched on
top of bonding interfaces? In case of parallel interface initialization
we would like to ensure that vlans are initialized after bonding interfaces
are brought up.

If it does solve this problem as well possibly no other modifications
to ifupdown are needed in the scenario I need to handle. If it does
not - I will try to alter my current implementation to use
per-interface stanzas.

 -- 
 Met vriendelijke groet / with kind regards,
   Guus Sliepen g...@debian.org

Regards,
Dariusz Gadomski


signature.asc
Description: Digital signature

Bug#753755: Patch proposal to fix the race condition

[Dariusz Gadomski]

Hello Maintainers!

After some discussions with Rafael and users affected by the race
condition I have prepared a patch solving the problem by introducing a
new stanza to the interfaces file:
allow-group-X-Y interfaces
where:
X is the group index
Y is the level in the hierarchy

This stanza allows to group interfaces into hierarchies to ensure
hierarchy locking below any given interface while ifupdown operates on
it.

E.g. if we have a bond0 interface built on top of eth0 and eth1 the
user would have to add the following to the interfaces file:
allow-group-1-1 bond0
allow-group-1-2 eth0 eth1

This would cause locking of eth0 and eth1 from any modification while
bond0 is handled by ifupdown.

If this stanza is not used the behaviour of ifupdown should be unchanged.

I have tested it together with a group of interested users in several
scenarios, but we were focusing mostly on the bonding scenario as this
was the case affecting the deployment I was interested in.

Please let me know what you think about it.

Thanks,
Dariusz Gadomski
# HG changeset patch
# User Dariusz Gadomski dariusz.gadom...@canonical.com
# Date 1433853683 -7200
#  Tue Jun 09 14:41:23 2015 +0200
# Branch hierarchical-lock
# Node ID e19ae508cd99bc374728fab8bc4f915f4088eb15
# Parent  e45cc73e740e1517fd0162e02336d648dfbb7b70
Added hierarchical interface locking.
This feature requires new stanza allow-group-X-Y in /etc/network/interfaces.
Without using this stanza the behaviour remains unchanged.
Additionally the interface state files have been splitted into individual
file for each interface residing in /run/network/state.

diff -r e45cc73e740e -r e19ae508cd99 config.c
--- a/config.c	Fri Mar 13 13:20:21 2015 +0100
+++ b/config.c	Tue Jun 09 14:41:23 2015 +0200
@@ -22,6 +22,11 @@
 allowup_defn *add_allow_up(char *filename, int line,
 allowup_defn * allow_up, char *iface_name);
 
+int parse_group(allowup_defn *allow_ups, long *group, long *level);
+int insert_into_hierarchy(interface_hierarchy *hierarchy,
+char *iface, long level);
+
+
 variable *set_variable(char *filename, char *name, char *value,
 variable ** var, int *n_vars, int *max_vars)
 {
@@ -466,6 +471,7 @@
 if (!add_allow_up(filename, line, allow_ups, firstword))
 return NULL;
 }
+
 currently_processing = NONE;
 } else {
 switch (currently_processing) {
@@ -725,3 +731,117 @@
 allow_up-n_interfaces++;
 return allow_up;
 }
+
+int parse_group(allowup_defn *allow_ups, long *group, long *level)
+{
+char *next;
+char *sep = strchr(allow_ups-when, '-');
+
+if (group == NULL || level == NULL)
+return -1;
+
+if (!sep)
+{
+*group = -1;
+*level = -1;
+return -1;
+}
+
+*group = strtol(sep+1, next, 10);
+*level = strtol(next+1, NULL, 10);
+
+if (*group == 0L || *level == 0L)
+{
+*group = -1;
+*level = -1;
+return -1;
+}
+
+return 0;
+}
+
+interface_hierarchy *find_iface_hierarchy(interfaces_file *defn, const char *iface)
+{
+interface_hierarchy *result=NULL;
+int iface_num;
+long base_group;
+long base_level;
+long group;
+long level;
+int found_group = 0;
+
+allowup_defn *allowups = defn-allowups;
+for (; allowups  !found_group; allowups = allowups-next) {
+if (strncmp(allowups-when, group-, 6) == 0)
+{
+for(iface_num=0; iface_numallowups-n_interfaces; ++iface_num)
+{
+if (iface  !strcmp(allowups-interfaces[iface_num], iface))
+{
+if (!parse_group(allowups, base_group, base_level))
+{
+// identified group of the interface in question
+result = malloc(sizeof(interface_hierarchy));
+result-iface = iface;
+result-level = base_level;
+result-next = NULL;
+result-prev = NULL;
+found_group = 1;
+break;
+}
+}
+}
+}
+}
+
+if (found_group)
+{
+allowup_defn *allowups = defn-allowups;
+for (; allowups ; allowups = allowups-next) {
+if (strncmp(allowups-when, group-, 6) == 0)
+{
+if (!parse_group(allowups, group, level))
+{
+if (group == base_group  level  base_level)
+{
+for(iface_num=0; iface_numallowups-n_interfaces; ++iface_num)
+{
+insert_into_hierarchy(result, allowups-interfaces[iface_num], level);
+}
+}
+}
+}
+}
+}
+
+return result;
+}
+
+int insert_into_hierarchy(interface_hierarchy *hierarchy, char *iface, long level