ᛜ ~ # restart-services -u -N -> Searching for services that need to be restarted ... \BUG: could not determine parent pid of 8390 in '/proc/8390/stat'. BUG: Please open a bugreport for this on bugs.gentoo.org BUG: /proc/8390/stat: BUG: 8390 (munin-asyncd [�) S 1 8390 8390 0 -1 1077952768 18595023 0 6 0 2866 9216 0 0 20 0 1 0 151931916 21712896 3198 18446744073709551615 94016977829888 94016977834957 140729652673872 0 0 0 0 65665 16386 0 0 0 17 1 0 0 88 0 0 94016977845656 94016977846408 94016987381760 140729652677411 140729652677464 140729652677464 140729652678616 0 (After restart as dependency of munin-node): ᛜ ~ # ps ax |grep munin-asyncd 28066 ? Ss 0:00 munin-asyncd [?] [idle] ᛜ ~ # cat /proc/28066/stat 28066 (munin-asyncd [�) S 1 28066 28066 0 -1 1077952768 90089 0 0 0 21 46 0 0 20 0 1 0 246914000 21667840 3548 18446744073709551615 94323606560768 94323606565837 140735280950320 0 0 0 0 65665 16386 0 0 0 17 1 0 0 0 0 0 94323606576536 94323606577288 94323612192768 140735280958243 140735280958296 140735280958296 140735280959448 0 looks like kernel fails with surrogates pairs see also: https://bugs.gentoo.org/721402 Reproducible: Always
Thanks for reporting, can you reproduce this?
Yes, I saw "Reproducible: Always", but my question was more about "can you do it *now*". Because for me it is not reproducable. Maybe you can attach the content of /proc/<pid>/stat to this bug so that charset will not be mangled somehow. And please have a look at line 129 in restart-services where $ppid_regex is defined. I cannot see any reason why it would not work for you. Do you?
> Maybe you can attach the content of /proc/<pid>/stat Sure: ᛜ ~ # cat /proc/28066/stat 28066 (munin-asyncd [�) S 1 28066 28066 0 -1 1077952768 5028781 0 0 0 804 2534 0 0 20 0 1 0 246914000 21667840 3555 18446744073709551615 94323606560768 94323606565837 140735280950320 0 0 0 0 65665 16386 0 0 0 17 1 0 0 21 0 0 94323606576536 94323606577288 94323612192768 140735280958243 140735280958296 140735280958296 140735280959448 0 ᛜ ~ # cat /proc/28066/stat |hexdump -C 00000000 32 38 30 36 36 20 28 6d 75 6e 69 6e 2d 61 73 79 |28066 (munin-asy| 00000010 6e 63 64 20 5b e1 29 20 53 20 31 20 32 38 30 36 |ncd [.) S 1 2806| ^----------------------------------------^ 00000020 36 20 32 38 30 36 36 20 30 20 2d 31 20 31 30 37 |6 28066 0 -1 107| 00000030 37 39 35 32 37 36 38 20 35 30 32 38 37 38 31 20 |7952768 5028781 | [...] I can't reproduce all restart-service script because... you yourself understand why, but I was able to do this: ᛜ ~ # r='^[0-9]+ (\([^\)]+\))'; s=`cat /proc/28066/stat`; echo $s; if [[ $s =~ $r ]]; then echo "${BASH_REMATCH[1]}"; else echo no; fi; 28066 (munin-asyncd [�) S 1 28066 28066 0 [...] no removed ending parenthesis in regexp: # r='^[0-9]+ (\([^\)]+)'; s=`cat /proc/28066/stat`; echo $s; if [[ $s =~ $r ]]; then echo "${BASH_REMATCH[1]}"; else echo no; fi; 28066 (munin-asyncd [�) S 1 28066 28066 0 [...] (munin-asyncd [ try with replace: ᛜ ~ # cat /proc/28066/stat | sed -E 's/^[0-9]+ (\([^\)]+)/TTTT/g' TTTT�) S 1 28066 28066 0 [...] that's why regexp doesn't work we need to drop broken codes via "iconv -f UTF-8 -t UTF-8 -c" ᛜ ~ # cat /proc/28066/stat | iconv -f UTF-8 -t UTF-8 -c |sed -E 's/^[0-9]+ (\([^\)]+)/TTTT/g' TTTT) S 1 28066 28066 0 [...] ᛜ ~ # r='^[0-9]+ (\([^\)]+\))'; s=`cat /proc/28066/stat | iconv -f UTF-8 -t UTF-8 -c `; echo $s; if [[ $s =~ $r ]]; then echo "${BASH_REMATCH[1]}"; else echo no; fi;28066 (munin-asyncd [) S 1 28066 28066 0 [...] (munin-asyncd [) hope I gave a full description of the problem
That helps a lot, thank you!
OK, thanks again. Fix will be in 0.15.2 diff --git a/restart-services b/restart-services index bc041de..9127314 100755 --- a/restart-services +++ b/restart-services @@ -127,7 +127,9 @@ function top_level_ppid() { local pid=$1 local stat local ppid_regex='^[0-9]+ \([^\)]+\) . ([0-9]+) .*' - read stat 2>/dev/null <"/proc/$pid/stat" || return 1 + # grsec denies ".... </proc/pid/stat", but "cat /proc/pid/stat" is allowed + # iconv: see bug #726768 + stat="$(cat "/proc/$pid/stat" | iconv -f UTF-8 -t UTF-8 -c)" || return 1 if [[ $stat =~ $ppid_regex ]]; then local ppid=${BASH_REMATCH[1]} else
I am having the same problem, but with the already-patches version 15.2. The reason for me seems to be that the stat output contains braces. The issue started with Samba 4.13.0 which uses tfork waiter processes: ps -ef | grep tfork root 16736 16667 0 Sep24 ? 00:00:00 samba: tfork waiter process(16738) root 16739 16667 0 Sep24 ? 00:00:00 samba: tfork waiter process(16741) root 16740 16738 0 Sep24 ? 00:00:00 samba: tfork waiter process(16743) root 16742 16667 0 Sep24 ? 00:00:00 samba: tfork waiter process(16744) root 16745 16667 0 Sep24 ? 00:00:00 samba: tfork waiter process(16747) ... cat /proc/16736/stat 16736 (tfork(16738)) S 16667 16667 16667 0 -1 4210752 95 0 0 0 0 0 0 0 20 0 1 0 1044476523 199303168 6040 18446744073709551615 94601555152896 94601555179221 140727787527056 0 0 0 6784 1048576 17505 0 0 0 17 7 0 0 0 0 0 94601555195968 94601555199104 94601573748736 140727787531170 140727787531186 140727787531186 140727787532264 0 The regular expression on line 994 does not match therefor: local ppid_regex='^[0-9]+ \([^\)]+\) . ([0-9]+) .*' I have replaced it by this line: local ppid_regex='^[0-9]+ \([^ ]+\) . ([0-9]+) .*' This fixes the issue for me - assuming the process name does not contain any spaces. I am not fully sure though if this is the case by specification
(In reply to Rainer Meier from comment #6) > I am having the same problem, but with the already-patches version 15.2. Thanks for reporting. > I have replaced it by this line: > local ppid_regex='^[0-9]+ \([^ ]+\) . ([0-9]+) .*' > I am quite sure this will also work and should be safe then: local ppid_regex='^[0-9]+ \(.*\) . ([0-9]+) .*' can you confirm this?
fixed in 0.16.1
Yes, the regular expression provided does work under those conditions too: local ppid_regex='^[0-9]+ \(.*\) . ([0-9]+) .*' However there is some risk of overmatching. Just imagine the string might contain another () combination (eg. towards the end of the stat) and therefore the regular expression might match all the way to the latest closing brace (at least if it is still followed by a space, single character/number and another number. I personally would consider the "non-space" match more safe as I expect the output of stat to be space-separated and therefore not allowing spaces within any of the fields. But confirmed matching any character upon the last closing brace does work in the case I reported.
(In reply to Rainer Meier from comment #9) > Yes, the regular expression provided does work under those conditions too: > > local ppid_regex='^[0-9]+ \(.*\) . ([0-9]+) .*' > > However there is some risk of overmatching. Just imagine the string might > contain another () combination (eg. towards the end of the stat) and > therefore the regular expression might match all the way to the latest > closing brace (at least if it is still followed by a space, single > character/number and another number. I did not find any spec of that file. But as I understand it, only the proc-name is in braces propably because it is the only value here that *can* contain spaces or any other arbitrary characters. All other fields are purely numerical or a single char. > I personally would consider the "non-space" match more safe as I expect the > output of stat to be space-separated and therefore not allowing spaces > within any of the fields. I disagree here because I think the only reason that braces are being used here might be the fact that it *can* contain spaces. > > But confirmed matching any character upon the last closing brace does work > in the case I reported. Thanks for reporting back!
