Damien Zammit, le mar. 02 févr. 2021 18:56:59 +1100, a ecrit:
> Here is the tail of my start up log with some extra debug mach_prints:
> I think the "Must be started as a translator" is coming from the netfs start
> up
Yes, a priori that's probably netfs_startup, and it probably needs to be
modif
Damien Zammit, le mar. 02 févr. 2021 18:29:42 +1100, a ecrit:
> [PATCH 2/3] Bootstrappable pci-arbiter
>
> This is a work in progress, I would like some comments on how I can
> make the arbiter start up without a / filesystem when it needs to
> expose the pci interface netfs on a real node.
That
Applied, thanks!
Paul Dufresne, le mar. 02 févr. 2021 13:34:39 -0500, a ecrit:
> So what should we do?
We can just relax and use the version I have uploaded to debian-ports
(2:3.3.16-5+hurd.1). There will probably not be any other upload of
procps until the release, and even if there is one I can just upload a
re-
So the interesting patch(
https://gitlab.com/procps-ng/procps/-/commit/bb96fc42956c9ed926a1b958ab715f8b4a663dec
) was done:
Jan 4 2020
In my opinion that patch should fix the problem.
Current stable version of procps (3.3.16) was released Dec, 7 2019 (about 1
month before the patch).
There is
Paul Dufresne, le mar. 02 févr. 2021 13:02:27 -0500, a ecrit:
> Upstream was changed:
>
> [1]https://gitlab.com/procps-ng/procps/-/blob/master/pgrep.c
>
> long cmdlen = get_arg_max() * sizeof(char);
>
> where get_arg_max is defined as:
That should be fine indeed.
Thanks for the fix! That'll be
Upstream was changed:
https://gitlab.com/procps-ng/procps/-/blob/master/pgrep.c
long cmdlen = get_arg_max() * sizeof(char);
where get_arg_max is defined as:
/*
* SC_ARG_MAX used to return the maximum size a command line can be
* however changes to the kernel mean this can be bigger than we
Paul Dufresne, le mar. 02 févr. 2021 12:30:25 -0500, a ecrit:
> I think it is cleaner like this:
>
> root@kibar:~/procps-3.3.16# diff -u ../orig/procps-3.3.16/pgrep.c pgrep.c
> --- ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
> +++ pgrep.c 2021-02-02 12:24:49.000
I think it is cleaner like this:
root@kibar:~/procps-3.3.16# diff -u ../orig/procps-3.3.16/pgrep.c pgrep.c
--- ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
+++ pgrep.c 2021-02-02 12:24:49.0 -0500
@@ -494,10 +494,15 @@
pid_t saved_pid = 0;
Paul Dufresne, le mar. 02 févr. 2021 12:05:54 -0500, a ecrit:
> root@kibar:~/procps-3.3.16# diff -u pgrep.c ../orig/procps-3.3.16/pgrep.c
> --- pgrep.c 2021-02-02 11:39:44.0 -0500
> +++ ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
> @@ -498,8 +498,6 @@
>
Grrhh! Sorry! Had diff arguments in reverse orders.
root@kibar:~/procps-3.3.16# diff -u ../orig/procps-3.3.16/pgrep.c pgrep.c
--- ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
+++ pgrep.c 2021-02-02 11:39:44.0 -0500
@@ -498,6 +498,8 @@
pid_t myse
Paul Dufresne, le mar. 02 févr. 2021 11:11:41 -0500, a ecrit:
> So -1 surely means error for sysconf.
No, see man sysconf:
If name corresponds to a maximum or minimum limit, and that limit is
indeterminate, -1 is returned and errno is not changed.
Samuel
root@kibar:~/procps-3.3.16# diff -u pgrep.c ../orig/procps-3.3.16/pgrep.c
--- pgrep.c 2021-02-02 11:39:44.0 -0500
+++ ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
@@ -498,8 +498,6 @@
pid_t myself = getpid();
struct el *list = NULL;
Paul Dufresne, le mar. 02 févr. 2021 09:34:54 -0500, a ecrit:
> 500 long cmdlen = sysconf(_SC_ARG_MAX) * sizeof(char);
This is bogus: sysconf is allowed to return -1 to tell that there is no
limitation.
Samuel
Sorry, because in previous posts, it seems code was not exactly the same as
source code.
I now came to the following conclusion:
main (argc=2, argv=0x1032e24) at pgrep.c:935
935 procs = select_procs (&num);
(gdb) s
select_procs (num=0x1032d60) at pgrep.c:489
489 {
(gdb) s
Oops forgot to mention one command in previous post:
In previous post:
#DEB_BUILD_OPTIONS="nostrip noopt" apt -b source procps
root@kibar:~/procps-3.3.16# file /usr/bin/pgrep
Corrected info:
#DEB_BUILD_OPTIONS="nostrip noopt" apt -b source procps
#apt install ./*.deb
root@kibar:~/pro
(gdb) l
429 {
430 PROCTAB *ptp;
431 int flags = 0;
432
433 if (opt_pattern || opt_full || opt_longlong)
434 flags |= PROC_FILLCOM;
435 if (opt_ruid || opt_rgid)
436 flags |= PROC_FILLSTATUS;
43
Code seems to make an abnormal call... I think:
I include the first part to show that you need to cd to the source code
directory for gdb to show you source lines.
root@kibar:~# gdb pgrep
GNU gdb (Debian 10.1-1.7+hurd.1) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc
On 2 Feb 2021, at 12:57, Samuel Thibault wrote:
>
> Paul Dufresne, le mar. 02 févr. 2021 07:47:53 -0500, a ecrit:
>> sh: 1: dpkg-source: not found
>
> apt-file search dpkg-source
> [...]
> dpkg-dev: /usr/bin/dpkg-source
Also apt even printed out:
> N: Check if the 'dpkg-dev' package is install
Paul Dufresne, le mar. 02 févr. 2021 07:47:53 -0500, a ecrit:
> sh: 1: dpkg-source: not found
apt-file search dpkg-source
[...]
dpkg-dev: /usr/bin/dpkg-source
Samuel
Using daily image of February 1, with updates for Perl. (I have no reason to
think Perl have something to do with the problem)
I normally don't use pgrep and pkill, but have decided to try them.
I get something like:
root@kibar:~# pgrep Xorg
pgrep: cannot allocate 4294967295 bytes
root@kiba
21 matches
Mail list logo
