[Touch-packages] [Bug 1837227] [NEW] Random mount units sometimes fail, while file system is correctly mounted
Public bug reported: In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1837227 Title: Random mount units sometimes fail, while file system is correctly mounted Status in systemd package in Ubuntu: New Bug description: In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837227/+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 1803530] [NEW] [Xenial][udev] postinst script should use "invoke-rc.d stop" instead of "systemctl stop"
Public bug reported:
In order to respect the local initscript policy layer that may be
present in /usr/sbin/policy-rc.d, the postinst script of the udev
package should use "invoke-rc.d stop" instead of "systemctl stop".
This direct systemctl call can be found in the handle_service_rename()
function :
handle_service_rename() {
if dpkg --compare-versions "$2" lt "204-1"; then
if [ -d /run/systemd/system ]; then
systemctl stop udev.service udev-control.socket udev-kernel.socket
>/dev/null 2>&1 || true
fi
fi
}
Using "systemctl stop" during unattended-upgrades in shutdown mode hangs
and leaves the dpkg database in a broken state after reboot. Using a
local initscript policy layer that prevents start/stop/restart actions
on this case is a way to prevent those hangs but maintainer scripts have
to use invoke-rc.d instead of direct systemctl calls.
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1803530
Title:
[Xenial][udev] postinst script should use "invoke-rc.d stop" instead
of "systemctl stop"
Status in systemd package in Ubuntu:
New
Bug description:
In order to respect the local initscript policy layer that may be
present in /usr/sbin/policy-rc.d, the postinst script of the udev
package should use "invoke-rc.d stop" instead of "systemctl stop".
This direct systemctl call can be found in the handle_service_rename()
function :
handle_service_rename() {
if dpkg --compare-versions "$2" lt "204-1"; then
if [ -d /run/systemd/system ]; then
systemctl stop udev.service udev-control.socket udev-kernel.socket
>/dev/null 2>&1 || true
fi
fi
}
Using "systemctl stop" during unattended-upgrades in shutdown mode
hangs and leaves the dpkg database in a broken state after reboot.
Using a local initscript policy layer that prevents start/stop/restart
actions on this case is a way to prevent those hangs but maintainer
scripts have to use invoke-rc.d instead of direct systemctl calls.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1803530/+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 1796376] Re: Bug #1739107 fix causes linux-cloud-tools-common not to be upgradable with unattended-upgrades on shutdown mode
Hi Eric, I confirm that this behaviour can only be reproduced in 'uu' context and only in 'shutdown mode'. I can also confirm that the upgrade process is now OK in Bionic with your test package : - unattended-upgrades version after the test package installation : ii unattended-upgrades 1.1ubuntu1.18.04.6+testpkgb1 all automatic installation of security upgrades - dpkg status for linux-cloud-tools-common after reboot + 'uu' in 'shutdown mode' : ii linux-cloud-tools-common 4.15.0-36.39 all Linux kernel version specific cloud tools for version 4.15.0 - APT logs for linux-cloud-tools-common : Start-Date: 2018-11-02 16:28:56 Commandline: /usr/bin/unattended-upgrade Upgrade: linux-cloud-tools-common:amd64 (4.15.0-34.37, 4.15.0-36.39) End-Date: 2018-11-02 16:29:01 Would it also be possible to backport the fix in Xenial, as this version is also impacted ? Thanks a lot for your help. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1796376 Title: Bug #1739107 fix causes linux-cloud-tools-common not to be upgradable with unattended-upgrades on shutdown mode Status in linux package in Ubuntu: Invalid Status in unattended-upgrades package in Ubuntu: Fix Released Status in linux source package in Bionic: Invalid Status in unattended-upgrades source package in Bionic: Confirmed Status in linux source package in Cosmic: Invalid Status in unattended-upgrades source package in Cosmic: Fix Released Status in linux source package in Disco: Invalid Status in unattended-upgrades source package in Disco: Fix Released Bug description: Since the following linux-cloud-tools-common package versions : Xenial : 4.4.0-135.161 Bionic : 4.15.0-34.37 the Systemd service unit file for hv-kvp-daemon has been modified with new dependencies that make the package unable to be upgraded with unattended-upgrades on shutdown mode. Unattended-upgrades hangs with the linux-cloud-tools-common package during "Preparing to unpack". The server restarts after the unattended-upgrades service timeout expires. - Package state after reboot : iFR linux-cloud-tools-common 4.15.0-34.37 all Linux kernel version specific cloud tools for version 4.15.0 - Unattended-upgrades dpkg logs : Log started: 2018-10-05 17:59:04 (Reading database ... 52043 files and directories currently installed.) Preparing to unpack .../linux-cloud-tools-common_4.15.0-36.39_all.deb ... Log ended: 2018-10-05 18:00:54 - Impact : The current impact is very important as all security updates are blocked until you manually fix each server with : dpkg --configure -a apt install --only-upgrade linux-cloud-tools-common - Workaround/Fix : As a simple straightforward fix, replacing : Before=shutdown.target cloud-init-local.service walinuxagent.service with : Before=shutdown.target walinuxagent.service makes the package upgradable during shutdown. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1796376/+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 1645636] Re: deadlock during lvm snapshot
Hi all, I think we just hit the same bug on a Production server today, with a snapshot on the root filesystem. Here are the relevant logs : kernel: [455151.056975] INFO: task jbd2/dm-0-8:214 blocked for more than 120 seconds. kernel: [455151.149417] INFO: task dmeventd:27193 blocked for more than 120 seconds. kernel: [455151.241272] INFO: task cat:27522 blocked for more than 120 seconds. ... All I/Os on the filesystem were blocked, so we had to reboot the server. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1645636 Title: deadlock during lvm snapshot Status in lvm2 package in Ubuntu: Confirmed Bug description: I'm doing backup of a running mongodb using LVM snapshot. Sometimes I run into a deadlock situation and kernel reports blocked tasks for jbd2, mongod, dmeventd and my tar doing backup. This happens very rarely (one in a thousand) but the effect is rather severe as mongodb stops working. I also can't remove and unmount the snapshot. I have Ubuntu 16.04.1 (lvm2 2.02.133-1ubuntu10) with mongod 3.2.9 on a 64bit system. According to the link below its a kernel race with considerably decreased chance in latest lvm2 package. https://www.redhat.com/archives/linux-lvm/2016-November/msg00037.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1645636/+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 1618900] [NEW] [Xenial/0.90] Systemd dependencies issues when used in "Shutdown mode"
Public bug reported: Using unattended-upgrades 0.90 in "Shutdown mode" on Ubuntu Xenial, we encounter the following systemd dependencies issues : - The network is often down when unattended-upgrades is running, so packages can not be downloaded (can be mitigated by using APT::Periodic::Download-Upgradeable-Packages "1";) : => ERROR An error occurred: 'Could not resolve host: .fr' => ERROR The URI 'https://.fr:33000/ubuntu-security/pool/main/libi/libidn/libidn11_1.32-3ubuntu1.1_amd64.deb' failed to download, aborting - Important mountpoints like /boot are unmounted before unattended-upgrades is running, so newer kernels can not be installed properly (ramdisk and grub configuration can not be generated) ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1618900 Title: [Xenial/0.90] Systemd dependencies issues when used in "Shutdown mode" Status in unattended-upgrades package in Ubuntu: New Bug description: Using unattended-upgrades 0.90 in "Shutdown mode" on Ubuntu Xenial, we encounter the following systemd dependencies issues : - The network is often down when unattended-upgrades is running, so packages can not be downloaded (can be mitigated by using APT::Periodic::Download-Upgradeable-Packages "1";) : => ERROR An error occurred: 'Could not resolve host: .fr' => ERROR The URI 'https://.fr:33000/ubuntu-security/pool/main/libi/libidn/libidn11_1.32-3ubuntu1.1_amd64.deb' failed to download, aborting - Important mountpoints like /boot are unmounted before unattended-upgrades is running, so newer kernels can not be installed properly (ramdisk and grub configuration can not be generated) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1618900/+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 1514428] Re: pvmove hangs while moving LVs
Some more information about this problem : We wanted to pvmove approximately 600GB of data between two (VMWare) disks : /dev/sdb and /dev/sdc - With database activity (PostgreSQL) : pvmove hangs exactly at the same point (60%) - Without database activity (PostgreSQL) : pvmove finishes correctly -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1514428 Title: pvmove hangs while moving LVs Status in lvm2 package in Ubuntu: New Bug description: Operating System : Ubuntu 12.04 LTS LVM version : 2.02.66-4ubuntu7.1 When trying to pvmove from one device to another on an active production system, it seems that we encounter the following bug : https://bugzilla.redhat.com/show_bug.cgi?id=706036 Symptoms : - pvmove command hangs indefinitely - iostat shows busy disks without any I/O - dmesg shows : kernel: [119143.641376] INFO: task jbd2/dm-5-8:1801 blocked for more than 120 seconds. kernel: [119143.641456] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [119143.641529] jbd2/dm-5-8 D 81806200 0 1801 2 0x kernel: [119143.641535] 88022d489ac0 0046 88022d489a60 8103ec29 kernel: [119143.641540] 88022d489fd8 88022d489fd8 88022d489fd8 00012800 kernel: [119143.641543] 880232169700 880227d0ae00 88022d489a90 88023fc930c0 kernel: [119143.641547] Call Trace: kernel: [119143.641561] [] ? default_spin_lock_flags+0x9/0x10 kernel: [119143.641568] [] ? __lock_page+0x70/0x70 kernel: [119143.641577] [] schedule+0x3f/0x60 kernel: [119143.641580] [] io_schedule+0x8f/0xd0 kernel: [119143.641584] [] sleep_on_page+0xe/0x20 kernel: [119143.641587] [] __wait_on_bit+0x5f/0x90 kernel: [119143.641590] [] wait_on_page_bit+0x78/0x80 kernel: [119143.641595] [] ? autoremove_wake_function+0x40/0x40 kernel: [119143.641598] [] filemap_fdatawait_range+0x10c/0x1a0 kernel: [119143.641603] [] ? dm_request+0x28/0x40 kernel: [119143.641607] [] ? generic_make_request.part.52+0x74/0xb0 kernel: [119143.641610] [] ? generic_make_request+0x68/0x70 kernel: [119143.641613] [] filemap_fdatawait+0x2b/0x30 kernel: [119143.641617] [] journal_finish_inode_data_buffers+0x70/0x170 kernel: [119143.641621] [] jbd2_journal_commit_transaction+0x677/0x12a0 kernel: [119143.641625] [] ? try_to_del_timer_sync+0xa4/0x110 kernel: [119143.641629] [] kjournald2+0xbb/0x220 kernel: [119143.641632] [] ? add_wait_queue+0x60/0x60 kernel: [119143.641635] [] ? commit_timeout+0x10/0x10 kernel: [119143.641638] [] kthread+0x8c/0xa0 kernel: [119143.641646] [] kernel_thread_helper+0x4/0x10 kernel: [119143.641649] [] ? flush_kthread_worker+0xa0/0xa0 kernel: [119143.641652] [] ? gs_change+0x13/0x13 The system has been resetted in order to become operational. I'm unable to use apport-collect on our servers as it does not seem to use proxy settings. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1514428/+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 1514428] [NEW] pvmove hangs while moving LVs
Public bug reported: Operating System : Ubuntu 12.04 LTS LVM version : 2.02.66-4ubuntu7.1 When trying to pvmove from one device to another on an active production system, it seems that we encounter the following bug : https://bugzilla.redhat.com/show_bug.cgi?id=706036 Symptoms : - pvmove command hangs indefinitely - iostat shows busy disks without any I/O - dmesg shows : kernel: [119143.641376] INFO: task jbd2/dm-5-8:1801 blocked for more than 120 seconds. kernel: [119143.641456] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [119143.641529] jbd2/dm-5-8 D 81806200 0 1801 2 0x kernel: [119143.641535] 88022d489ac0 0046 88022d489a60 8103ec29 kernel: [119143.641540] 88022d489fd8 88022d489fd8 88022d489fd8 00012800 kernel: [119143.641543] 880232169700 880227d0ae00 88022d489a90 88023fc930c0 kernel: [119143.641547] Call Trace: kernel: [119143.641561] [] ? default_spin_lock_flags+0x9/0x10 kernel: [119143.641568] [] ? __lock_page+0x70/0x70 kernel: [119143.641577] [] schedule+0x3f/0x60 kernel: [119143.641580] [] io_schedule+0x8f/0xd0 kernel: [119143.641584] [] sleep_on_page+0xe/0x20 kernel: [119143.641587] [] __wait_on_bit+0x5f/0x90 kernel: [119143.641590] [] wait_on_page_bit+0x78/0x80 kernel: [119143.641595] [] ? autoremove_wake_function+0x40/0x40 kernel: [119143.641598] [] filemap_fdatawait_range+0x10c/0x1a0 kernel: [119143.641603] [] ? dm_request+0x28/0x40 kernel: [119143.641607] [] ? generic_make_request.part.52+0x74/0xb0 kernel: [119143.641610] [] ? generic_make_request+0x68/0x70 kernel: [119143.641613] [] filemap_fdatawait+0x2b/0x30 kernel: [119143.641617] [] journal_finish_inode_data_buffers+0x70/0x170 kernel: [119143.641621] [] jbd2_journal_commit_transaction+0x677/0x12a0 kernel: [119143.641625] [] ? try_to_del_timer_sync+0xa4/0x110 kernel: [119143.641629] [] kjournald2+0xbb/0x220 kernel: [119143.641632] [] ? add_wait_queue+0x60/0x60 kernel: [119143.641635] [] ? commit_timeout+0x10/0x10 kernel: [119143.641638] [] kthread+0x8c/0xa0 kernel: [119143.641646] [] kernel_thread_helper+0x4/0x10 kernel: [119143.641649] [] ? flush_kthread_worker+0xa0/0xa0 kernel: [119143.641652] [] ? gs_change+0x13/0x13 The system has been resetted in order to become operational. I'm unable to use apport-collect on our servers as it does not seem to use proxy settings. ** Affects: lvm2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1514428 Title: pvmove hangs while moving LVs Status in lvm2 package in Ubuntu: New Bug description: Operating System : Ubuntu 12.04 LTS LVM version : 2.02.66-4ubuntu7.1 When trying to pvmove from one device to another on an active production system, it seems that we encounter the following bug : https://bugzilla.redhat.com/show_bug.cgi?id=706036 Symptoms : - pvmove command hangs indefinitely - iostat shows busy disks without any I/O - dmesg shows : kernel: [119143.641376] INFO: task jbd2/dm-5-8:1801 blocked for more than 120 seconds. kernel: [119143.641456] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [119143.641529] jbd2/dm-5-8 D 81806200 0 1801 2 0x kernel: [119143.641535] 88022d489ac0 0046 88022d489a60 8103ec29 kernel: [119143.641540] 88022d489fd8 88022d489fd8 88022d489fd8 00012800 kernel: [119143.641543] 880232169700 880227d0ae00 88022d489a90 88023fc930c0 kernel: [119143.641547] Call Trace: kernel: [119143.641561] [] ? default_spin_lock_flags+0x9/0x10 kernel: [119143.641568] [] ? __lock_page+0x70/0x70 kernel: [119143.641577] [] schedule+0x3f/0x60 kernel: [119143.641580] [] io_schedule+0x8f/0xd0 kernel: [119143.641584] [] sleep_on_page+0xe/0x20 kernel: [119143.641587] [] __wait_on_bit+0x5f/0x90 kernel: [119143.641590] [] wait_on_page_bit+0x78/0x80 kernel: [119143.641595] [] ? autoremove_wake_function+0x40/0x40 kernel: [119143.641598] [] filemap_fdatawait_range+0x10c/0x1a0 kernel: [119143.641603] [] ? dm_request+0x28/0x40 kernel: [119143.641607] [] ? generic_make_request.part.52+0x74/0xb0 kernel: [119143.641610] [] ? generic_make_request+0x68/0x70 kernel: [119143.641613] [] filemap_fdatawait+0x2b/0x30 kernel: [119143.641617] [] journal_finish_inode_data_buffers+0x70/0x170 kernel: [119143.641621] [] jbd2_journal_commit_transaction+0x677/0x12a0 kernel: [119143.641625] [] ? try_to_del_timer_sync+0xa4/0x110 kernel: [119143.641629] [] kjournald2+0xbb/0x220 kernel: [119143.641632] [] ? add_wait_queue+0x60/0x60 kernel: [119143.641635] [] ? commit_timeout+0x10/0x10 kernel: [119143.641638] [] kthread+0x8c/0xa0 kernel:
