Bug#996839: [PATCH v3] perf script flamegraph: Avoid d3-flame-graph package dependency
On 18.01.23 08:24, Ian Rogers wrote:
Currently flame graph generation requires a d3-flame-graph template to
be installed. Unfortunately this is hard to come by for things like
Debian [1]. If the template isn't installed then ask if it should be
downloaded from jsdelivr CDN. The downloaded HTML file is validated
against an md5sum. If the download fails, generate a minimal flame
graph with the javascript coming from links to jsdelivr CDN.
v3. Adds a warning message and quits before download in live mode.
v2. Change the warning to a prompt about downloading and add the
--allow-download command line flag. Add an md5sum check for the
downloaded HTML.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839
Signed-off-by: Ian Rogers
---
I've tested the new functionality on Fedora 37 and everything works.
On second thought, now the flame graph script will not only also work on
Debian (and derivatives), but on all distributions without needing a new
package for each distribution. That's a great improvement - thank you
for the changes!
Reviewed-by: Andreas Gerstmayr
Thanks,
Andreas
tools/perf/scripts/python/flamegraph.py | 107 +++-
1 file changed, 85 insertions(+), 22 deletions(-)
diff --git a/tools/perf/scripts/python/flamegraph.py
b/tools/perf/scripts/python/flamegraph.py
index b6af1dd5f816..cf7ce8229a6c 100755
--- a/tools/perf/scripts/python/flamegraph.py
+++ b/tools/perf/scripts/python/flamegraph.py
@@ -19,12 +19,34 @@
# pylint: disable=missing-function-docstring
from __future__ import print_function
-import sys
-import os
-import io
import argparse
+import hashlib
+import io
import json
+import os
import subprocess
+import sys
+import urllib.request
+
+minimal_html = """
+ https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.css";>
+
+
+
+ https://d3js.org/d3.v7.js"</a>;>
+ https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.min.js"</a>;>
+
+ const stacks = [/** @flamegraph_json **/];
+ // Note, options is unused.
+ const options = [/** @options_json **/];
+
+ var chart = flamegraph();
+ d3.select("#chart")
+.datum(stacks[0])
+.call(chart);
+
+
+"""
# pylint: disable=too-few-public-methods
class Node:
@@ -50,16 +72,6 @@ class FlameGraphCLI:
self.args = args
self.stack = Node("all", "root")
-if self.args.format == "html" and \
-not os.path.isfile(self.args.template):
-print("Flame Graph template {} does not exist. Please install "
- "the js-d3-flame-graph (RPM) or libjs-d3-flame-graph (deb) "
- "package, specify an existing flame graph template "
- "(--template PATH) or another output format "
- "(--format FORMAT).".format(self.args.template),
- file=sys.stderr)
-sys.exit(1)
-
@staticmethod
def get_libtype_from_dso(dso):
"""
@@ -128,16 +140,63 @@ class FlameGraphCLI:
}
options_json = json.dumps(options)
+template_md5sum = None
+if self.args.format == "html":
+if os.path.isfile(self.args.template):
+template = f"file://{self.args.template}"
+else:
+if not self.args.allow_download:
+print(f"""Warning: Flame Graph template
'{self.args.template}'
+does not exist. To avoid this please install a package such as the
+js-d3-flame-graph or libjs-d3-flame-graph, specify an existing flame
+graph template (--template PATH) or use another output format (--format
+FORMAT).""",
+ file=sys.stderr)
+if self.args.input == "-":
+print("""Not attempting to download Flame Graph
template as script command line
+input is disabled due to using live mode. If you want to download the
+template retry without live mode. For example, use 'perf record -a -g
+-F 99 sleep 60' and 'perf script report flamegraph'. Alternatively,
+download the template from:
+https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/templates/d3-flamegraph-base.html
+and place it at:
+/usr/share/d3-flame-graph/d3-flamegraph-base.html""",
+ file=sys.stderr)
+quit()
+s = None
+while s != "y" and s != "n":
+s = input("Do you wish to download a template from
cdn.jsdelivr.net? (this warning can be suppressed with --allow-download) [yn]
").lower()
+
Bug#996839: [PATCH v2] perf script flamegraph: Avoid d3-flame-graph package dependency
On 12.01.23 23:00, Ian Rogers wrote:
Currently flame graph generation requires a d3-flame-graph template to
be installed. Unfortunately this is hard to come by for things like
Debian [1]. If the template isn't installed then ask if it should be
downloaded from jsdelivr CDN. The downloaded HTML file is validated
against an md5sum. If the download fails, generate a minimal flame
graph with the javascript coming from links to jsdelivr CDN.
v2. Change the warning to a prompt about downloading and add the
--allow-download command line flag. Add an md5sum check for the
downloaded HTML.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839
Signed-off-by: Ian Rogers
Thank you for the changes. I've tested v2 with:
* d3-flame-graph package installed
* template not installed, download template from jsdelivr
* download from jsdelivr, with --allow-download
* invalid checksum
* unreachable jsdelivr, creating a minimal template
Everything works great except when I'm invoking "perf script flamegraph
-a -F 99 sleep 10" (combining perf report + perf script):
[root@agerstmayr-thinkpad tmp]# perf script flamegraph -a -F 99 sleep 10
[...]
Warning: Flame Graph template
'/usr/share/d3-flame-graph/d3-flamegraph-base.html'
does not exist. To avoid this please install a package such as the
js-d3-flame-graph or libjs-d3-flame-graph, specify an existing flame
graph template (--template PATH) or use another output format (--format
FORMAT).
Do you wish to download a template from cdn.jsdelivr.net? (this warning
can be suppressed with --allow-download) [yn] Traceback (most recent
call last):
File "/usr/libexec/perf-core/scripts/python/flamegraph.py", line 157,
in trace_end
s = input("Do you wish to download a template from
cdn.jsdelivr.net? (this warning can be suppressed with --allow-download)
[yn] ").lower()
^^^
OSError: [Errno 9] Bad file descriptor
Fatal Python error: handler_call_die: problem in Python trace event handler
Python runtime state: initialized
Current thread 0x7ff4053a3cc0 (most recent call first):
Extension modules: systemd._journal, systemd._reader, systemd.id128
(total: 3)
/usr/libexec/perf-core/scripts/python/bin/flamegraph-report: line 3:
2135491 Aborted (core dumped) perf script -s
"$PERF_EXEC_PATH"/scripts/python/flamegraph.py -- "$@"
iirc when running "perf script flamegraph" the perf.data gets piped to
stdin of the flamegraph script, so we can't ask the user in this case.
You can check this condition with `self.args.input == "-". Not sure
what's the best action in this case, maybe just exit?
Cheers,
Andreas
---
tools/perf/scripts/python/flamegraph.py | 96 +++--
1 file changed, 74 insertions(+), 22 deletions(-)
diff --git a/tools/perf/scripts/python/flamegraph.py
b/tools/perf/scripts/python/flamegraph.py
index b6af1dd5f816..086619053e4e 100755
--- a/tools/perf/scripts/python/flamegraph.py
+++ b/tools/perf/scripts/python/flamegraph.py
@@ -19,12 +19,34 @@
# pylint: disable=missing-function-docstring
from __future__ import print_function
-import sys
-import os
-import io
import argparse
+import hashlib
+import io
import json
+import os
import subprocess
+import sys
+import urllib.request
+
+minimal_html = """
+ https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.css";>
+
+
+
+ https://d3js.org/d3.v7.js";>
+ https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.min.js";>
+
+ const stacks = [/** @flamegraph_json **/];
+ // Note, options is unused.
+ const options = [/** @options_json **/];
+
+ var chart = flamegraph();
+ d3.select("#chart")
+.datum(stacks[0])
+.call(chart);
+
+
+"""
# pylint: disable=too-few-public-methods
class Node:
@@ -50,16 +72,6 @@ class FlameGraphCLI:
self.args = args
self.stack = Node("all", "root")
-if self.args.format == "html" and \
-not os.path.isfile(self.args.template):
-print("Flame Graph template {} does not exist. Please install "
- "the js-d3-flame-graph (RPM) or libjs-d3-flame-graph (deb) "
- "package, specify an existing flame graph template "
- "(--template PATH) or another output format "
- "(--format FORMAT).".format(self.args.template),
- file=sys.stderr)
-sys.exit(1)
-
@staticmethod
def get_libtype_from_dso(dso):
"""
@@ -128,16 +140,52 @@ class FlameGraphCLI:
}
options_json = json.dumps(options)
+template_md5sum = None
+if self.args.format == "html":
+if os.path.isfile(self.args.template):
Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency
On 11.01.23 18:13, Ian Rogers wrote: On Wed, Jan 11, 2023 at 5:18 AM Andreas Gerstmayr wrote: On 10.01.23 20:51, Ian Rogers wrote: On Tue, Jan 10, 2023 at 10:02 AM Andreas Gerstmayr wrote: On 05.01.23 10:24, Ian Rogers wrote: On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers wrote: Currently flame graph generation requires a d3-flame-graph template to be installed. Unfortunately this is hard to come by for things like Debian [1]. If the template isn't installed warn and download it from jsdelivr CDN. If downloading fails generate a minimal flame graph again with the javascript coming from jsdelivr CDN. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839 Signed-off-by: Ian Rogers I'm not entirely convinced that this perf script should make a network request. In my opinion * best would be if this template gets packaged in Debian * alternatively print instructions how to install the template: sudo mkdir /usr/share/d3-flame-graph sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html * or eventually just embed the entire template (66 KB) in the Python file (not sure if this is permissible though, it's basically a minified HTML/JS blob)? * if the above options don't work, I'd recommend asking the user before making the network request, and eventually persist the template somewhere so it doesn't need to be downloaded every time What do you think? So the script following this patch is going to try 3 things: 1) look for a local template HTML, 2) if a local template isn't found warn and switch to downloading the CDN version, 3) if the CDN version fails to download then use a minimal (embedded in the script) HTML file with JS dependencies coming from the CDN. For (1) there are references in the generated HTML to www.w3.org, meaning the HTML isn't fully hermetic - although these references may not matter. The references to w3.org are XML namespace names. As far as I'm aware they do not matter, as they are merely identifiers and are never accessed [1,2]. Therefore the generated HTML file in its current form is hermetic. This was a design decision from the start - the flame graph generation and the resulting HTML file should not use any external resources loaded over the network (the external host could be inaccessible or compromised at any time). I understand that this requirement may not apply to every user or company. For (2) there will be a download from the CDN of the template during the execution of flamegraph. The template is better than (3) as it features additional buttons letting you zoom out, etc. The HTML will contain CDN references. For (3) the generated HTML isn't hermetic and will use the CDN. For (2) we could give a prompt before trying to download the template, or we could change it so that we give the wget command. I wouldn't have the wget command require root privileges, I'd say that the template could be downloaded and then the path of the download given as an option to the flamegraph program. Downloading the file and then adding an option to flamegraph seems inconvenient to the user, something that the use of urllib in the patch avoids - it is essentially just doing this for the user without storing the file on disk. I think I prefer to be less inconvenient, and so the state of the code at the moment looks best to me. Given that no choice results in a fully hermetic HTML file, they seem similar in this regard. Is it okay to try a download with urllib? Should there be a prompt? I think the warning is enough and allows scripts, etc. using flamegraph to more easily function across differing distributions. I fully agree, your changes make the flame graph generation more convenient in case the template is not installed. Also, downloading the template to a local directory and having to specify the path to the template every time is an inconvenience. I think it is a tradeoff between convenience and security/privacy. jsdelivr can get compromised, serving malicious JS (well, in that case, printing instructions to jsdelivr is also flawed :|). In the end it's up to the maintainers to decide. Agreed. It is something of an issue with the perf tool, I think noted by Arnaldo and Linus, that it has too many dependencies. We also have a problem that a number of dependencies aren't license compatible for distribution with perf's GPLv2. flamegraph.py is always installed but it carries a dependency that can't be satisfied on Debian and everything deriving from it. The prompting to install a package solution, as is generally used in the build, is one approach. Using http rather than files is the approach this change introduces, and is an approach advocated by the d3 flamegraph README.md. Perhaps package maintainers like Michael and Ben have opinions here. An aside, Namhyung pointed out to me th
Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency
On 10.01.23 20:51, Ian Rogers wrote: On Tue, Jan 10, 2023 at 10:02 AM Andreas Gerstmayr wrote: On 05.01.23 10:24, Ian Rogers wrote: On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers wrote: Currently flame graph generation requires a d3-flame-graph template to be installed. Unfortunately this is hard to come by for things like Debian [1]. If the template isn't installed warn and download it from jsdelivr CDN. If downloading fails generate a minimal flame graph again with the javascript coming from jsdelivr CDN. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839 Signed-off-by: Ian Rogers I'm not entirely convinced that this perf script should make a network request. In my opinion * best would be if this template gets packaged in Debian * alternatively print instructions how to install the template: sudo mkdir /usr/share/d3-flame-graph sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html * or eventually just embed the entire template (66 KB) in the Python file (not sure if this is permissible though, it's basically a minified HTML/JS blob)? * if the above options don't work, I'd recommend asking the user before making the network request, and eventually persist the template somewhere so it doesn't need to be downloaded every time What do you think? So the script following this patch is going to try 3 things: 1) look for a local template HTML, 2) if a local template isn't found warn and switch to downloading the CDN version, 3) if the CDN version fails to download then use a minimal (embedded in the script) HTML file with JS dependencies coming from the CDN. For (1) there are references in the generated HTML to www.w3.org, meaning the HTML isn't fully hermetic - although these references may not matter. The references to w3.org are XML namespace names. As far as I'm aware they do not matter, as they are merely identifiers and are never accessed [1,2]. Therefore the generated HTML file in its current form is hermetic. This was a design decision from the start - the flame graph generation and the resulting HTML file should not use any external resources loaded over the network (the external host could be inaccessible or compromised at any time). I understand that this requirement may not apply to every user or company. For (2) there will be a download from the CDN of the template during the execution of flamegraph. The template is better than (3) as it features additional buttons letting you zoom out, etc. The HTML will contain CDN references. For (3) the generated HTML isn't hermetic and will use the CDN. For (2) we could give a prompt before trying to download the template, or we could change it so that we give the wget command. I wouldn't have the wget command require root privileges, I'd say that the template could be downloaded and then the path of the download given as an option to the flamegraph program. Downloading the file and then adding an option to flamegraph seems inconvenient to the user, something that the use of urllib in the patch avoids - it is essentially just doing this for the user without storing the file on disk. I think I prefer to be less inconvenient, and so the state of the code at the moment looks best to me. Given that no choice results in a fully hermetic HTML file, they seem similar in this regard. Is it okay to try a download with urllib? Should there be a prompt? I think the warning is enough and allows scripts, etc. using flamegraph to more easily function across differing distributions. I fully agree, your changes make the flame graph generation more convenient in case the template is not installed. Also, downloading the template to a local directory and having to specify the path to the template every time is an inconvenience. I think it is a tradeoff between convenience and security/privacy. jsdelivr can get compromised, serving malicious JS (well, in that case, printing instructions to jsdelivr is also flawed :|). In the end it's up to the maintainers to decide. An aside, Namhyung pointed out to me that there is a "perf report -g folded" option, that was added in part to simplify creating flamegraphs: http://lkml.kernel.org/r/1447047946-1691-2-git-send-email-namhy...@kernel.org Building off of perf report may improve/simplify the flamegraph code, or avoid the requirement that libpython be linked against perf. Yep, in this case another tool is required to generate the flame graph visualization, for example [3]. [1] https://www.w3.org/TR/xml-names11/ [2] https://developer.mozilla.org/en-US/docs/Web/SVG/Namespaces_Crash_Course [3] https://github.com/brendangregg/FlameGraph Cheers, Andreas Thanks, Ian Cheers, Andreas --- tools/perf/scripts/python/flamegraph.py | 63 ++--- 1 file changed, 45 insertions(+
Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency
On 05.01.23 10:24, Ian Rogers wrote:
On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers wrote:
Currently flame graph generation requires a d3-flame-graph template to
be installed. Unfortunately this is hard to come by for things like
Debian [1]. If the template isn't installed warn and download it from
jsdelivr CDN. If downloading fails generate a minimal flame graph
again with the javascript coming from jsdelivr CDN.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839
Signed-off-by: Ian Rogers
I'm not entirely convinced that this perf script should make a network
request. In my opinion
* best would be if this template gets packaged in Debian
* alternatively print instructions how to install the template:
sudo mkdir /usr/share/d3-flame-graph
sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html
https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html
* or eventually just embed the entire template (66 KB) in the Python
file (not sure if this is permissible though, it's basically a minified
HTML/JS blob)?
* if the above options don't work, I'd recommend asking the user before
making the network request, and eventually persist the template
somewhere so it doesn't need to be downloaded every time
What do you think?
Cheers,
Andreas
---
tools/perf/scripts/python/flamegraph.py | 63 ++---
1 file changed, 45 insertions(+), 18 deletions(-)
diff --git a/tools/perf/scripts/python/flamegraph.py
b/tools/perf/scripts/python/flamegraph.py
index b6af1dd5f816..808b0e1c9be5 100755
--- a/tools/perf/scripts/python/flamegraph.py
+++ b/tools/perf/scripts/python/flamegraph.py
@@ -25,6 +25,27 @@ import io
import argparse
import json
import subprocess
+import urllib.request
+
+minimal_html = """
+ https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.css";>
(hopefully fixed Martin Spier's e-mail address)
The @4.1.3 comes from the README.md:
https://github.com/spiermar/d3-flame-graph/blob/master/README.md
Does it make sense just to drop it or use @latest ? It'd be nice not
to patch this file for every d3-flame-graph update.
Thanks,
Ian
+
+
+
+ https://d3js.org/d3.v7.js";>
+ https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.min.js";>
+
+ const stacks = [/** @flamegraph_json **/];
+ // Note, options is unused.
+ const options = [/** @options_json **/];
+
+ var chart = flamegraph();
+ d3.select("#chart")
+.datum(stacks[0])
+.call(chart);
+
+
+"""
# pylint: disable=too-few-public-methods
class Node:
@@ -50,15 +71,18 @@ class FlameGraphCLI:
self.args = args
self.stack = Node("all", "root")
-if self.args.format == "html" and \
-not os.path.isfile(self.args.template):
-print("Flame Graph template {} does not exist. Please install "
- "the js-d3-flame-graph (RPM) or libjs-d3-flame-graph (deb) "
- "package, specify an existing flame graph template "
- "(--template PATH) or another output format "
- "(--format FORMAT).".format(self.args.template),
- file=sys.stderr)
-sys.exit(1)
+if self.args.format == "html":
+if os.path.isfile(self.args.template):
+self.template = f"file://{self.args.template}"
+else:
+print(f"""
+Warning: Flame Graph template '{self.args.template}'
+does not exist, a template will be downloaded via http. To avoid this
+please install a package such as the js-d3-flame-graph or
+libjs-d3-flame-graph, specify an existing flame graph template
+(--template PATH) or another output format (--format FORMAT).
+""", file=sys.stderr)
+self.template =
"https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/templates/d3-flamegraph-base.html";
@staticmethod
def get_libtype_from_dso(dso):
@@ -129,15 +153,18 @@ class FlameGraphCLI:
options_json = json.dumps(options)
try:
-with io.open(self.args.template, encoding="utf-8") as template:
-output_str = (
-template.read()
-.replace("/** @options_json **/", options_json)
-.replace("/** @flamegraph_json **/", stacks_json)
-)
-except IOError as err:
-print("Error reading template file: {}".format(err),
file=sys.stderr)
-sys.exit(1)
+with urllib.request.urlopen(self.template) as template:
+output_str = '\n'.join([
+l.decode('utf-8') for l in template.readlines()
+])
+except Exception as err:
+print(f"Error reading template {self.template}: {err}\n"
+ "a minimal flame graph will be generated",
file=sys.stderr)
+output_str = minimal_ht
Bug#989385: redisearch.so needs executable permissions
Package: redis-redisearch
Version: 1.2.2-3
The /usr/lib/redis/modules/redisearch.so file needs executable
permissions, otherwise Redis won't start.
Quick reproducer in a container:
root@c47b056bcc1f:/# apt-get update && apt-get install -y sudo
redis-redisearch
[...]
root@c47b056bcc1f:/# sudo -u redis redis-server --loadmodule
/usr/lib/redis/modules/redisearch.so
290:C 02 Jun 2021 12:10:34.530 # oO0OoO0OoO0Oo Redis is starting
oO0OoO0OoO0Oo
290:C 02 Jun 2021 12:10:34.530 # Redis version=6.0.14, bits=64,
commit=, modified=0, pid=290, just started
290:C 02 Jun 2021 12:10:34.530 # Configuration loaded
_._
_.-``__ ''-._
_.-```. `_. ''-._ Redis 6.0.14 (/0) 64 bit
.-`` .-```. ```\/_.,_ ''-._
(' , .-` | `,) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
|`-._ `._/ _.-'| PID: 290
`-._`-._ `-./ _.-'_.-'
|`-._`-._`-.__.-'_.-'_.-'|
|`-._`-.__.-'_.-'| http://redis.io
`-._`-._`-.__.-'_.-'_.-'
|`-._`-._`-.__.-'_.-'_.-'|
|`-._`-.__.-'_.-'|
`-._`-._`-.__.-'_.-'_.-'
`-._`-.__.-'_.-'
`-.__.-'
`-.__.-'
290:M 02 Jun 2021 12:10:34.534 # Server initialized
290:M 02 Jun 2021 12:10:34.534 # WARNING overcommit_memory is set to 0!
Background save may fail under low memory condition. To fix this issue
add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or
run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
290:M 02 Jun 2021 12:10:34.534 # Module
/usr/lib/redis/modules/redisearch.so failed to load: It does not have
execute permissions.
290:M 02 Jun 2021 12:10:34.534 # Can't load module from
/usr/lib/redis/modules/redisearch.so: server aborting
root@c47b056bcc1f:/# ls -lh /usr/lib/redis/modules/redisearch.so
-rw-r--r--. 1 root root 2.0M Apr 23 2020
/usr/lib/redis/modules/redisearch.so
root@c47b056bcc1f:/# chmod +x /usr/lib/redis/modules/redisearch.so
root@c47b056bcc1f:/# sudo -u redis redis-server --loadmodule
/usr/lib/redis/modules/redisearch.so
294:C 02 Jun 2021 12:10:53.581 # oO0OoO0OoO0Oo Redis is starting
oO0OoO0OoO0Oo
294:C 02 Jun 2021 12:10:53.581 # Redis version=6.0.14, bits=64,
commit=, modified=0, pid=294, just started
294:C 02 Jun 2021 12:10:53.581 # Configuration loaded
_._
_.-``__ ''-._
_.-```. `_. ''-._ Redis 6.0.14 (/0) 64 bit
.-`` .-```. ```\/_.,_ ''-._
(' , .-` | `,) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
|`-._ `._/ _.-'| PID: 294
`-._`-._ `-./ _.-'_.-'
|`-._`-._`-.__.-'_.-'_.-'|
|`-._`-.__.-'_.-'| http://redis.io
`-._`-._`-.__.-'_.-'_.-'
|`-._`-._`-.__.-'_.-'_.-'|
|`-._`-.__.-'_.-'|
`-._`-._`-.__.-'_.-'_.-'
`-._`-.__.-'_.-'
`-.__.-'
`-.__.-'
294:M 02 Jun 2021 12:10:53.584 # Server initialized
294:M 02 Jun 2021 12:10:53.585 # WARNING overcommit_memory is set to 0!
Background save may fail under low memory condition. To fix this issue
add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or
run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
294:M 02 Jun 2021 12:10:53.587 * RediSearch version 1.2.0 (Git=)
294:M 02 Jun 2021 12:10:53.587 * concurrency: ON, gc: ON, prefix
min length: 2, prefix max expansions: 200, query timeout (ms): 500,
timeout policy: return, cursor read size: 1000, cursor max idle (ms):
30, max doctable size: 100, search pool size: 20, index pool
size: 8,
294:M 02 Jun 2021 12:10:53.588 * Initialized thread pool!
294:M 02 Jun 2021 12:10:53.588 * Module 'ft' loaded from
/usr/lib/redis/modules/redisearch.so
294:M 02 Jun 2021 12:10:53.588 * Ready to accept connections
^C294:signal-handler (1622635855) Received SIGINT scheduling shutdown...
294:M 02 Jun 2021 12:10:55.999 # User requested shutdown...
294:M 02 Jun 2021 12:10:55.999 # Redis is now ready to exit, bye bye...
Problem occurs with Debian bullseye and sid, it works fine on buster. I
guess it's a change in Redis version 6.
Cheers,
Andreas
Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Hi, On 07.01.20 08:56, Martin Pitt wrote: Ken and Andreas, this would mean we set Debian8 (and the equivalent Ubuntu release) as the minimum required for Makepkgs builds. Would that be a problem for anyone? It turns out that was the first Debian that used systemd as the init system, so there's a possibility of several other useful packaging cleanups if we take this path. Note that Debian 8 went EOL some time ago. There are some efforts to provide security update maintenance for it, but that doesn't mean that you still have to support it upstream -- these security updates would only do selected patch backports, not new upstream releases. Debian 9 should still be supported for roughly another half year. (See https://www.debian.org/releases/) +1 I'd be happy if we can remove the complexity of supporting two init systems and two Python versions (at least for Debian now). Cheers, Andreas
