Bug#892193: lvm2: Debian 9 fails to boot from the LV on a multipath device
Package: lvm2 Version: 2.02.168-2 Severity: important Dear Maintainer, there is a problem with booting Debian Stretch from LV on a multipath device (I have multipath-tools-boot installed). At initramfs, logical volumes are activated by udev as soon as the disks appear, so lvm complains that there are duplicate VGs found. Later on, multipath says that it cannot use one of the devices, because it is in use - there already are active LVs on top of it. Further situation depends on configuration. In legacy BIOS mode and everything on LVs, the system continues to boot using a single path - device mapper has already mapped LVs to /dev/mapper/* and /dev/VG/*. In UEFI mode (EFI partition directly on a multipath device, /dev/mapper/WWID-partN in fstab), however, it exits to the initramfs shell, because the partitions are not mapped in /dev/mapper/. In that case the system does not boot, so this is a serious problem. Interestingly, the situation described above happens in about 80-90% of boots, sometimes everything works well. Some kind of race condition? I have found that the problem is caused by the option --disable-udev-systemd-background-jobs in package configuration. As a consequence, in /lib/udev/rules.d/69-lvm-metad.rules, pvscan is run directly. With package compiled with udev systemd background jobs enabled, it is run by /bin/systemd-run and everything works fine. In current versions of Jessie and even Sid, this option is enabled, so why was it disabled in Stretch? I believe that #870692 may also be related to this. Greetings, Piotr -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/40 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.137-2 ii dmsetup 2:1.02.137-2 ii init-system-helpers 1.48 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libdevmapper-event1.02.1 2:1.02.137-2 ii libdevmapper1.02.12:1.02.137-2 ii liblvm2app2.2 2.02.168-2 ii libreadline5 5.2+dfsg-3+b1 ii libudev1 232-25+deb9u1 ii lsb-base 9.20161125 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools -- no debconf information
Bug#876459: needrestart: Non-interactive mode not being detected properly
Package: needrestart
Version: 2.11-3
Severity: important
Tags: upstream patch
Dear Maintainer,
the problem described in the archived bug #803249 still exists in 2.11-3
(Debian 9.1). When needrestart is run without a tty AND with
DEBIAN_FRONTEND=noninteractive, it still tries to work interactively rather
than fall back to "list only" mode. In some cases it causes unwanted restarts.
The easiest way to reproduce it is to run needrestart from cron, redirecting
the output to a file.
I attach a patch that may work, but I'm not sure, as I know Perl only a little
and don't know other implementation details. In my case it is working as
expected.
The problem is rather serious. I use Ansible for automation and once I run it
to install something on an OpenVZ host. After installation by apt-get,
needrestart started to restart VZ containers, including the one from which
Ansible was run. I ended up with all the containers stopped!
Regards,
Piotr
-- System Information:
Debian Release: 9.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.bsd54g54 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages needrestart depends on:
ii dpkg 1.18.24
ii gettext-base 0.19.8.1-2
ii libintl-perl 1.26-2
ii libmodule-find-perl0.13-1
ii libmodule-scandeps-perl1.23-1
ii libproc-processtable-perl 0.53-2
ii libsort-naturally-perl 1.03-1
ii libterm-readkey-perl 2.37-1
ii perl 5.24.1-3+deb9u1
ii xz-utils 5.2.2-1.2+b1
Versions of packages needrestart recommends:
ii sysvinit-core 2.88dsf-59.9
Versions of packages needrestart suggests:
pn needrestart-session | libnotify-bin
-- no debconf information
--- needrestart-2.11.orig/needrestart
+++ needrestart-2.11/needrestart
@@ -181,7 +181,7 @@ $nrconf{ui} = qq(NeedRestart::UI::stdio)
die "Hook directory '$nrconf{hook_d}' is invalid!\n" unless(-d $nrconf{hook_d}
|| $opt_b);
$opt_r = $nrconf{restart} unless(defined($opt_r));
die "ERROR: Unknown restart option '$opt_r'!\n" unless($opt_r =~ /^(l|i|a)$/);
-$is_tty++ if($opt_r eq 'i' && exists($ENV{DEBIAN_FRONTEND}) &&
$ENV{DEBIAN_FRONTEND} eq 'noninteractive');
+$is_tty = 0 if($opt_r eq 'i' && exists($ENV{DEBIAN_FRONTEND}) &&
$ENV{DEBIAN_FRONTEND} eq 'noninteractive');
$opt_r = 'l' if(!$is_tty && $opt_r eq 'i');
$opt_m = $nrconf{ui_mode} unless(defined($opt_m));
Bug#876452: needrestart: Unnamed block devices (like for OpenVZ's simfs) not being detected properly
Package: needrestart
Version: 2.11-3
Severity: important
Tags: patch upstream
Dear Maintainer,
needrestart does not work properly on some OpenVZ containers - it always claims
that everything needs to be restarted. There was a bug report about that in the
upstream:
https://github.com/liske/needrestart/issues/28
but the solution given there (already included in Debian) does not cover all
cases. As written in the kernel docs
(https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt),
unnamed device major number is not always 0, it can also be 144, 145 and 146.
I've made a simple patch to handle that.
Regards,
Piotr
-- System Information:
Debian Release: 9.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.bsd54g54 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages needrestart depends on:
ii dpkg 1.18.24
ii gettext-base 0.19.8.1-2
ii libintl-perl 1.26-2
ii libmodule-find-perl0.13-1
ii libmodule-scandeps-perl1.23-1
ii libproc-processtable-perl 0.53-2
ii libsort-naturally-perl 1.03-1
ii libterm-readkey-perl 2.37-1
ii perl 5.24.1-3+deb9u1
ii xz-utils 5.2.2-1.2+b1
Versions of packages needrestart recommends:
ii sysvinit-core 2.88dsf-59.9
Versions of packages needrestart suggests:
pn needrestart-session | libnotify-bin
-- no debconf information
--- needrestart-2.11.orig/needrestart
+++ needrestart-2.11/needrestart
@@ -472,9 +472,9 @@ if(defined($opt_l)) {
# Don't compare device numbers on anon filesystems
# w/o a backing device (like OpenVZ's simfs).
+ my $major = (($sdev >> 8) & 0xfff) | (($sdev >> 32) &
~0xfff);
$mdev = "00:00"
- if $sdev >> 8) & 0xfff) |
-(($sdev >> 32) & ~0xfff)) == 0);
+ if ($major == 0 || $major == 144 || $major == 145
|| $major == 146);
# compare maps content vs. on-disk
unless($minode eq $sinode && ((grep {$mdev eq $_}
@sdevs) ||
Bug#778303: chef: Memory leak
Hello again,
I think that is a serious regression. If you manage to make it work
correctly, please do get in touch and we can prepare a stable update for
the memory leak.
I think I've done it, looking at the source of chef 11.12.8-2 (from
Jessie). I'm not a programmer and I know Ruby only a little, so it would
probably be possible to do it better, but it's been working fine on
about 150 nodes for over 5 months. The stacktrace is still visable in
the output (and also in logs), but the chef-stacktrace.out file is also
produced properly, including the forked client stacktrace. I attach the
patch and chef-stacktrace.out files to compare - from modified Wheezy
package and from Jessie.
Is the result satisfying?
adding new features in a stable update is generally not a good idea,
no matter what.
OK, I understand. However, I found another bug in the package, related
to FileEdit. Both the issue and the solution is here:
https://github.com/chef/chef/pull/754
Please let me know if it is possible to apply it together with the
forked runs (technically it is), or should I open another issue.
--
Greetings,
Piotr Pańczyk
Asseco Business Solutions S.A.
ul. Konrada Wallenroda 4c
20-607 Lublin
tel.: +48 81 535 30 00
fax: +48 81 535 30 05
Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku
VI Wydział Gospodarczy Krajowego Rejestru Sądowego
KRS 028257
NIP 522-26-12-717
kapitał zakładowy 167 090 965,00 zł (w całości opłacony)
www.assecobs.pl
Powyższa korespondencja przeznaczona jest wyłącznie dla osoby lub podmiotu, do
którego jest adresowana i może zawierać informacje o charakterze poufnym lub
zastrzeżonym. Nieuprawnione wykorzystanie informacji zawartych w wiadomości
e-mail przez osobę lub podmiot nie będący jej adresatem jest zabronione
odpowiednimi przepisami prawa. Odbiorca korespondencji, który otrzymał ją
omyłkowo, proszony jest o niezwłoczne zawiadomienie nadawcy drogą elektroniczną
lub telefonicznie i usunięcie tej treści z poczty elektronicznej. Dziękujemy.
Asseco Business Solutions S.A.
Weź pod uwagę ochronę środowiska, zanim wydrukujesz ten e-mail.
This information is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Unauthorized
use of this information by person or entity other than the intended recipient
is prohibited by law. If you received this by mistake, please immediately
contact the sender by e-mail or by telephone and delete this information from
any computer. Thank you. Asseco Business Solutions S.A.
Please consider your environmental responsibility before printing this e-mail.
--- chef-10.12.0.orig/lib/chef/config.rb
+++ chef-10.12.0/lib/chef/config.rb
@@ -184,6 +184,7 @@ class Chef
run_command_stdout_timeout 120
solo false
splay nil
+client_fork true
# Set these to enable SSL authentication / mutual-authentication
# with the server
--- chef-10.12.0.orig/lib/chef/daemon.rb
+++ chef-10.12.0/lib/chef/daemon.rb
@@ -24,6 +24,7 @@ class Chef
class Daemon
class << self
attr_accessor :name
+ attr_accessor :forked_child
# Daemonize the current process, managing pidfiles and process uid/gid
#
@@ -46,7 +47,7 @@ class Chef
$stdout.reopen("/dev/null", "a")
$stderr.reopen($stdout)
save_pid_file
-at_exit { remove_pid_file }
+at_exit { remove_pid_file unless forked_child }
rescue NotImplementedError => e
Chef::Application.fatal!("There is no fork: #{e.message}")
end
--- chef-10.12.0.orig/lib/chef/client.rb
+++ chef-10.12.0/lib/chef/client.rb
@@ -36,6 +36,7 @@ require 'chef/cookbook/file_vendor'
require 'chef/cookbook/file_system_file_vendor'
require 'chef/cookbook/remote_file_vendor'
require 'chef/version'
+require 'chef/daemon'
require 'ohai'
require 'rbconfig'
@@ -135,50 +136,52 @@ class Chef
end
# Do a full run for this Chef::Client. Calls:
+# * do_run
#
-# * run_ohai - Collect information about the system
-# * build_node - Get the last known state, merge with local changes
-# * register - If not in solo mode, make sure the server knows about this client
-# * sync_cookbooks - If not in solo mode, populate the local cache with the node's cookbooks
-# * converge - Bring this system up to date
-#
+# This provides a wrapper around #do_run allowing the
+# run to be optionally forked.
# === Returns
-# true:: Always returns true.
+# boolean:: Return value from #do_run. Should always returns true.
def run
- run_context = nil
-
- Chef::Log.info("*** Chef #{Chef::VERSION} ***")
- enforce_path_sanity
- run_ohai
- register unless Che
Bug#778303: chef: Memory leak
Hello again,
I did manage to apply those two commits manually:
https://github.com/chef/chef/commit/d99e497874e7d08f017376717aa38a4c8d7fecd5
https://github.com/chef/chef/commit/6c10604f1e8e9b557b69449b484df3aae47ee468
omitting a few lines related to some intermediate versions.
Forking is working correctly, the result is visualized in attached munin
grapph. I also attach the diff result.
Such modified client has been used on about 80 servers for over 2
months. The only problem I noticed is that if client run fails, the
stacktrace.out file only contains stacktrace from the parent process.
Child stacktrace is printed out to stderr (it's not included in logs,
visible only while executing the manual, single run). I've made some
custom modifications comparing files with chef 11.12, but I think the
result is not yet what we really expect. If you want to look at it,
please let me know.
If you decide to backport the package, I would suggest to add one small
feature (from newer versions) by chance - I really miss the file_edited?
method in Chef::Util::FileEdit. It's just one getter, the diff is also
attached.
--
Greetings,
Piotr Pańczyk
Asseco Business Solutions S.A.
ul. Konrada Wallenroda 4c
20-607 Lublin
tel.: +48 81 535 30 00
fax: +48 81 535 30 05
Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku
VI Wydział Gospodarczy Krajowego Rejestru Sądowego
KRS 028257
NIP 522-26-12-717
kapitał zakładowy 167 090 965,00 zł (w całości opłacony)
www.assecobs.pl
Powyższa korespondencja przeznaczona jest wyłącznie dla osoby lub podmiotu, do
którego jest adresowana i może zawierać informacje o charakterze poufnym lub
zastrzeżonym. Nieuprawnione wykorzystanie informacji zawartych w wiadomości
e-mail przez osobę lub podmiot nie będący jej adresatem jest zabronione
odpowiednimi przepisami prawa. Odbiorca korespondencji, który otrzymał ją
omyłkowo, proszony jest o niezwłoczne zawiadomienie nadawcy drogą elektroniczną
lub telefonicznie i usunięcie tej treści z poczty elektronicznej. Dziękujemy.
Asseco Business Solutions S.A.
Weź pod uwagę ochronę środowiska, zanim wydrukujesz ten e-mail.
This information is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Unauthorized
use of this information by person or entity other than the intended recipient
is prohibited by law. If you received this by mistake, please immediately
contact the sender by e-mail or by telephone and delete this information from
any computer. Thank you. Asseco Business Solutions S.A.
Please consider your environmental responsibility before printing this e-mail.
--- chef-10.12.0.orig/lib/chef/config.rb
+++ chef-10.12.0/lib/chef/config.rb
@@ -184,6 +184,7 @@ class Chef
run_command_stdout_timeout 120
solo false
splay nil
+client_fork true
# Set these to enable SSL authentication / mutual-authentication
# with the server
--- chef-10.12.0.orig/lib/chef/daemon.rb
+++ chef-10.12.0/lib/chef/daemon.rb
@@ -24,6 +24,7 @@ class Chef
class Daemon
class self
attr_accessor :name
+ attr_accessor :forked_child
# Daemonize the current process, managing pidfiles and process uid/gid
#
@@ -46,7 +47,7 @@ class Chef
$stdout.reopen(/dev/null, a)
$stderr.reopen($stdout)
save_pid_file
-at_exit { remove_pid_file }
+at_exit { remove_pid_file unless forked_child }
rescue NotImplementedError = e
Chef::Application.fatal!(There is no fork: #{e.message})
end
--- chef-10.12.0.orig/lib/chef/client.rb
+++ chef-10.12.0/lib/chef/client.rb
@@ -135,48 +135,29 @@ class Chef
end
# Do a full run for this Chef::Client. Calls:
+# * do_run
#
-# * run_ohai - Collect information about the system
-# * build_node - Get the last known state, merge with local changes
-# * register - If not in solo mode, make sure the server knows about this client
-# * sync_cookbooks - If not in solo mode, populate the local cache with the node's cookbooks
-# * converge - Bring this system up to date
-#
+# This provides a wrapper around #do_run allowing the
+# run to be optionally forked.
# === Returns
-# true:: Always returns true.
+# boolean:: Return value from #do_run. Should always returns true.
def run
- run_context = nil
-
- Chef::Log.info(*** Chef #{Chef::VERSION} ***)
- enforce_path_sanity
- run_ohai
- register unless Chef::Config[:solo]
- build_node
-
- begin
-
-run_status.start_clock
-Chef::Log.info(Starting Chef Run for #{node.name})
-run_started
-
-run_context = setup_run_context
-converge(run_context)
-save_updated_node
Bug#778303: chef: Memory leak
Hello Antonio, I think the simple, ad ad-hoc solution can be changing the default logrotate period from a week to a day, which would slightly reduce the amount of wasted memory, as logrotate restarts the daemon. The problem is quite serious for us, especially on servers running a lot of virtual machines. If you manage to apply the commits related to the forking behaviour, I can test the package for you. On 22.02.2015 03:16, Antonio Terceiro wrote: Hello Piotr, On Fri, Feb 13, 2015 at 03:56:38PM +0100, Piotr Pańczyk wrote: Hello Antonio, On 13.02.2015 14:29, Antonio Terceiro wrote: Would you by any chance be able to identify the upstream commit that introduced the fix? If so, I can try backporting that and releasing a stable update. I think this is it: https://github.com/chef/chef/pull/291 I was looking at this, and there a few issues: - that commit does not apply clean on the wheezy chef tree. - there are are a few other commits in the upstream history related to the forking behaviour, so I think there were a few issues with this it. I have the the impression that it is too risky to pull this into a stable branch, and I won't have to spare cycles to handle the breakage that will probably come. - I only use chef-solo, so testing this would a little difficult for me. -- Greetings, Piotr Pańczyk Asseco Business Solutions S.A. ul. Konrada Wallenroda 4c 20-607 Lublin tel.: +48 81 535 30 00 fax: +48 81 535 30 05 Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku VI Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 028257 NIP 522-26-12-717 kapitał zakładowy 167 090 965,00 zł (w całości opłacony) www.assecobs.pl Powyższa korespondencja przeznaczona jest wyłącznie dla osoby lub podmiotu, do którego jest adresowana i może zawierać informacje o charakterze poufnym lub zastrzeżonym. Nieuprawnione wykorzystanie informacji zawartych w wiadomości e-mail przez osobę lub podmiot nie będący jej adresatem jest zabronione odpowiednimi przepisami prawa. Odbiorca korespondencji, który otrzymał ją omyłkowo, proszony jest o niezwłoczne zawiadomienie nadawcy drogą elektroniczną lub telefonicznie i usunięcie tej treści z poczty elektronicznej. Dziękujemy. Asseco Business Solutions S.A. Weź pod uwagę ochronę środowiska, zanim wydrukujesz ten e-mail. This information is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Unauthorized use of this information by person or entity other than the intended recipient is prohibited by law. If you received this by mistake, please immediately contact the sender by e-mail or by telephone and delete this information from any computer. Thank you. Asseco Business Solutions S.A. Please consider your environmental responsibility before printing this e-mail.
Bug#778303: chef: Memory leak
Hello Antonio, On 13.02.2015 14:29, Antonio Terceiro wrote: Would you by any chance be able to identify the upstream commit that introduced the fix? If so, I can try backporting that and releasing a stable update. I think this is it: https://github.com/chef/chef/pull/291 -- Greetings, Piotr Pańczyk Asseco Business Solutions S.A. ul. Konrada Wallenroda 4c 20-607 Lublin tel.: +48 81 535 30 00 fax: +48 81 535 30 05 Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku VI Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 028257 NIP 522-26-12-717 kapitał zakładowy 167 090 965,00 zł (w całości opłacony) www.assecobs.pl Powyższa korespondencja przeznaczona jest wyłącznie dla osoby lub podmiotu, do którego jest adresowana i może zawierać informacje o charakterze poufnym lub zastrzeżonym. Nieuprawnione wykorzystanie informacji zawartych w wiadomości e-mail przez osobę lub podmiot nie będący jej adresatem jest zabronione odpowiednimi przepisami prawa. Odbiorca korespondencji, który otrzymał ją omyłkowo, proszony jest o niezwłoczne zawiadomienie nadawcy drogą elektroniczną lub telefonicznie i usunięcie tej treści z poczty elektronicznej. Dziękujemy. Asseco Business Solutions S.A. Weź pod uwagę ochronę środowiska, zanim wydrukujesz ten e-mail. This information is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Unauthorized use of this information by person or entity other than the intended recipient is prohibited by law. If you received this by mistake, please immediately contact the sender by e-mail or by telephone and delete this information from any computer. Thank you. Asseco Business Solutions S.A. Please consider your environmental responsibility before printing this e-mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773698: chef-server-api: Error 500 returned by Chef Server
Package: chef-server-api Version: 10.12.0-1 Severity: normal Dear Maintainer, I'm getting error 500 (Net::HTTPFatalError: 500 Internal Server Error) from Chef Server when running the client, probably due to big amount of data returned by Ohai. I tried connecting the same node to newer version of Chef Server (Open Source Chef Server 11.1.6-1 downloaded from Chef's website) and it returned Net::HTTPServerException: 413 Request Entity Too Large. The workaround is to disable passwd plugin in Ohai, but I'd prefer to store all data on the server. Please consider extending the data limit. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32.bsd54h0 (SMP w/24 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages chef-server-api depends on: ii adduser 3.113+nmu3 ii chef 10.12.0-3 ii chef-solr 10.12.0+dfsg-2 ii couchdb 1.2.0-5 ii merb-core 1.1.3+dfsg-2 ii rabbitmq-server 3.4.2-1 ii ruby 1:1.9.3 ii ruby-dep-selector 0.0.8-1 ii ruby-json 1.7.3-3 ii ruby-merb-assets 1.1.3-1 ii ruby-merb-core [merb-core]1.1.3+dfsg-2 ii ruby-merb-haml1.1.3-2 ii ruby-merb-helpers 1.1.3-1 ii ruby-merb-param-protection1.1.3-1 ii ruby-mixlib-authentication1.1.4-2 ii ruby-treetop 1.4.10-5 ii ruby-uuidtools2.1.2-2 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1+deb7u2 ii thin 1.3.1-3 ii ucf 3.0025+nmu3 chef-server-api recommends no packages. chef-server-api suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
