Activity log for bug #1876600

Date Who What changed Old value New value Message
2020-05-03 16:34:01 Heitor Alves de Siqueira bug added bug
2020-05-04 12:47:10 Fabio Augusto Miranda Martins bug added subscriber Fabio Augusto Miranda Martins
2020-05-04 16:05:53 Heitor Alves de Siqueira nominated for series Ubuntu Xenial
2020-05-04 16:05:53 Heitor Alves de Siqueira bug task added systemd (Ubuntu Xenial)
2020-05-04 16:05:53 Heitor Alves de Siqueira nominated for series Ubuntu Bionic
2020-05-04 16:05:53 Heitor Alves de Siqueira bug task added systemd (Ubuntu Bionic)
2020-05-04 16:06:00 Heitor Alves de Siqueira systemd (Ubuntu): status New Fix Released
2020-05-04 16:06:02 Heitor Alves de Siqueira systemd (Ubuntu Xenial): status New Confirmed
2020-05-04 16:06:03 Heitor Alves de Siqueira systemd (Ubuntu Bionic): status New Confirmed
2020-05-04 16:06:06 Heitor Alves de Siqueira systemd (Ubuntu Xenial): importance Undecided High
2020-05-04 16:06:08 Heitor Alves de Siqueira systemd (Ubuntu Bionic): importance Undecided High
2020-05-04 16:06:11 Heitor Alves de Siqueira systemd (Ubuntu Bionic): assignee Heitor Alves de Siqueira (halves)
2020-05-04 16:06:12 Heitor Alves de Siqueira systemd (Ubuntu Xenial): assignee Heitor Alves de Siqueira (halves)
2020-05-05 12:19:09 Heitor Alves de Siqueira description [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages usually include a "cookie" value to uniquely identify them in their bus context. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to hang. This has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.27 | xenial-security | source, ... systemd | 229-4ubuntu21.27 | xenial-updates | source, ... systemd | 229-4ubuntu21.28 | xenial-proposed | source, ... systemd | 237-3ubuntu10 | bionic | source, ... systemd | 237-3ubuntu10.38 | bionic-security | source, ... systemd | 237-3ubuntu10.39 | bionic-updates | source, ... systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <---- systemd | 242-7ubuntu3 | eoan | source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.27 | xenial-security | source, ... systemd | 229-4ubuntu21.27 | xenial-updates | source, ... systemd | 229-4ubuntu21.28 | xenial-proposed | source, ... systemd | 237-3ubuntu10 | bionic | source, ... systemd | 237-3ubuntu10.38 | bionic-security | source, ... systemd | 237-3ubuntu10.39 | bionic-updates | source, ... systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <---- systemd | 242-7ubuntu3 | eoan | source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects This is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x10000, and set its value to 0xffffff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x00010000 reply-cookie: 0x00010000 Breakpoint 1, print_unit_path (bus=0x555555757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, &m, $1 = 0x10000 $2 = 0xffffff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests.
2020-05-05 12:19:26 Heitor Alves de Siqueira summary cookie overruns cause org.freedesktop.systemd1 dbus to hang cookie overruns can cause org.freedesktop.systemd1 dbus to hang
2020-05-05 12:19:49 Heitor Alves de Siqueira attachment added test.c https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+attachment/5366779/+files/test.c
2020-05-05 12:20:01 Heitor Alves de Siqueira attachment added test.gdb https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+attachment/5366780/+files/test.gdb
2020-05-05 12:24:00 Heitor Alves de Siqueira description [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.27 | xenial-security | source, ... systemd | 229-4ubuntu21.27 | xenial-updates | source, ... systemd | 229-4ubuntu21.28 | xenial-proposed | source, ... systemd | 237-3ubuntu10 | bionic | source, ... systemd | 237-3ubuntu10.38 | bionic-security | source, ... systemd | 237-3ubuntu10.39 | bionic-updates | source, ... systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <---- systemd | 242-7ubuntu3 | eoan | source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects This is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x10000, and set its value to 0xffffff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x00010000 reply-cookie: 0x00010000 Breakpoint 1, print_unit_path (bus=0x555555757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, &m, $1 = 0x10000 $2 = 0xffffff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests. [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd  systemd | 229-4ubuntu4 | xenial | source, ...  systemd | 229-4ubuntu21.27 | xenial-security | source, ...  systemd | 229-4ubuntu21.27 | xenial-updates | source, ...  systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...  systemd | 237-3ubuntu10 | bionic | source, ...  systemd | 237-3ubuntu10.38 | bionic-security | source, ...  systemd | 237-3ubuntu10.39 | bionic-updates | source, ...  systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <----  systemd | 242-7ubuntu3 | eoan | source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x10000, and set its value to 0xffffff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x00010000 reply-cookie: 0x00010000 Breakpoint 1, print_unit_path (bus=0x555555757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, &m, $1 = 0x10000 $2 = 0xffffff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests.
2020-05-05 14:32:48 Launchpad Janitor merge proposal linked https://code.launchpad.net/~halves/ubuntu/+source/systemd/+git/systemd/+merge/383417
2020-05-05 14:33:06 Launchpad Janitor merge proposal linked https://code.launchpad.net/~halves/ubuntu/+source/systemd/+git/systemd/+merge/383418
2020-05-05 14:33:37 Heitor Alves de Siqueira tags sts sts sts-sponsor
2020-05-05 14:49:54 Heitor Alves de Siqueira description [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd  systemd | 229-4ubuntu4 | xenial | source, ...  systemd | 229-4ubuntu21.27 | xenial-security | source, ...  systemd | 229-4ubuntu21.27 | xenial-updates | source, ...  systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...  systemd | 237-3ubuntu10 | bionic | source, ...  systemd | 237-3ubuntu10.38 | bionic-security | source, ...  systemd | 237-3ubuntu10.39 | bionic-updates | source, ...  systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <----  systemd | 242-7ubuntu3 | eoan | source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x10000, and set its value to 0xffffff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x00010000 reply-cookie: 0x00010000 Breakpoint 1, print_unit_path (bus=0x555555757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, &m, $1 = 0x10000 $2 = 0xffffff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests. [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd  systemd | 229-4ubuntu4 | xenial | source, ...  systemd | 229-4ubuntu21.27 | xenial-security | source, ...  systemd | 229-4ubuntu21.27 | xenial-updates | source, ...  systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...  systemd | 237-3ubuntu10 | bionic | source, ...  systemd | 237-3ubuntu10.38 | bionic-security | source, ...  systemd | 237-3ubuntu10.39 | bionic-updates | source, ...  systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <----  systemd | 242-7ubuntu3 | eoan | source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x10000, and set its value to 0xffffff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x00010000 reply-cookie: 0x00010000 Breakpoint 1, print_unit_path (bus=0x555555757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, &m, $1 = 0x10000 $2 = 0xffffff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests.
2020-05-05 14:58:34 Heitor Alves de Siqueira systemd (Ubuntu Xenial): status Confirmed In Progress
2020-05-05 14:58:36 Heitor Alves de Siqueira systemd (Ubuntu Bionic): status Confirmed In Progress
2020-05-06 13:21:45 Dan Streetman tags sts sts-sponsor sts sts-sponsor-ddstreet
2020-05-06 13:21:55 Dan Streetman bug added subscriber STS Sponsors
2020-05-13 21:06:52 Dan Streetman bug added subscriber Dan Streetman
2020-05-14 20:36:28 Brian Murray systemd (Ubuntu Bionic): status In Progress Fix Committed
2020-05-14 20:36:30 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2020-05-14 20:36:33 Brian Murray bug added subscriber SRU Verification
2020-05-14 20:36:40 Brian Murray tags sts sts-sponsor-ddstreet sts sts-sponsor-ddstreet verification-needed verification-needed-bionic
2020-05-22 12:34:22 Heitor Alves de Siqueira tags sts sts-sponsor-ddstreet verification-needed verification-needed-bionic sts sts-sponsor-ddstreet verification-done verification-done-bionic
2020-05-25 08:17:27 Launchpad Janitor systemd (Ubuntu Bionic): status Fix Committed Fix Released
2020-05-25 08:17:45 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2020-09-04 08:32:01 Łukasz Zemczak systemd (Ubuntu Xenial): status In Progress Fix Committed
2020-09-04 08:32:03 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2020-09-04 08:32:07 Łukasz Zemczak tags sts sts-sponsor-ddstreet verification-done verification-done-bionic sts sts-sponsor-ddstreet verification-done-bionic verification-needed verification-needed-xenial
2020-09-09 19:15:01 Heitor Alves de Siqueira tags sts sts-sponsor-ddstreet verification-done-bionic verification-needed verification-needed-xenial sts sts-sponsor-ddstreet verification-done verification-done-bionic verification-done-xenial
2020-09-15 16:16:33 Launchpad Janitor systemd (Ubuntu Xenial): status Fix Committed Fix Released