Summary: | sys-process/cronbase-0.3.7-r1 with apps-shells/bash-4.4: /usr/sbin/run-crons: line 59: warning: command substitution: ignored null byte in input | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Craig Andrews <candrews> |
Component: | Current packages | Assignee: | Tobias Klausmann (RETIRED) <klausman> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | candrews |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 595276 |
Description
Craig Andrews
![]() How about --- run-crons-0.3.7 +++ run-crons-0.3.7-r1 @@ -56,9 +56,7 @@ # This is better than kill -0 because we can verify that it's really # another run-crons process. - cmdline1=$(cat "/proc/${cronpid}/cmdline" 2>/dev/null) || : - cmdline2=$(cat /proc/$$/cmdline) - if [ "${cmdline1}" = "${cmdline2}" ] ; then + if ! cmp "/proc/${cronpid}/cmdline" /proc/$$/cmdline ; then # Whoa, another run-crons is really running. return 1 fi (In reply to Felix Janda from comment #1) > How about > > --- run-crons-0.3.7 > +++ run-crons-0.3.7-r1 > @@ -56,9 +56,7 @@ > > # This is better than kill -0 because we can verify that it's really > # another run-crons process. > - cmdline1=$(cat "/proc/${cronpid}/cmdline" 2>/dev/null) || : > - cmdline2=$(cat /proc/$$/cmdline) > - if [ "${cmdline1}" = "${cmdline2}" ] ; then > + if ! cmp "/proc/${cronpid}/cmdline" /proc/$$/cmdline ; then > # Whoa, another run-crons is really running. > return 1 > fi That seems to work most of the time, but sometimes, I'm getting: cmp: /proc/28440/cmdline: No such file or directory I am having the same issue. I fixed it in commit 7c266d7a1854b3b1b543fb35036d3e4e6c3135cf: diff --git a/sys-process/cronbase/cronbase-0.3.7-r1.ebuild b/sys-process/cronbase/cronbase-0.3.7-r2.ebuild similarity index 100% rename from sys-process/cronbase/cronbase-0.3.7-r1.ebuild rename to sys-process/cronbase/cronbase-0.3.7-r2.ebuild diff --git a/sys-process/cronbase/files/run-crons-0.3.7 b/sys-process/cronbase/files/run-crons-0.3.7 index c661c77..c5f2d9c 100755 --- a/sys-process/cronbase/files/run-crons-0.3.7 +++ b/sys-process/cronbase/files/run-crons-0.3.7 @@ -56,8 +56,10 @@ grab_lock() { # This is better than kill -0 because we can verify that it's really # another run-crons process. - cmdline1=$(cat "/proc/${cronpid}/cmdline" 2>/dev/null) || : - cmdline2=$(cat /proc/$$/cmdline) + # The tr call deletes null bytes so newer bash versions do not complain + # about them. + cmdline1=$(tr -d '\0' < "/proc/${cronpid}/cmdline" 2>/dev/null) || : + cmdline2=$(tr -d '\0' < /proc/$$/cmdline) if [ "${cmdline1}" = "${cmdline2}" ] ; then # Whoa, another run-crons is really running. return 1 I'm still getting messages like this: /usr/sbin/run-crons: line 61: /proc/6450/cmdline: No such file or directory So I suspect there's more work to do. (In reply to candrews from comment #5) > I'm still getting messages like this: > /usr/sbin/run-crons: line 61: /proc/6450/cmdline: No such file or directory > > So I suspect there's more work to do. Can you check which of the two cmdline=... lines in /usr/sbin/run-crons is #61? I have a suspicion, but I want to make sure I get this right. Line 61 is: cmdline1=$(tr -d '\0' < "/proc/${cronpid}/cmdline" 2>/dev/null) || : (In reply to Tobias Klausmann from comment #6) > (In reply to candrews from comment #5) > > I'm still getting messages like this: > > /usr/sbin/run-crons: line 61: /proc/6450/cmdline: No such file or directory > > > > So I suspect there's more work to do. > > Can you check which of the two cmdline=... lines in /usr/sbin/run-crons is > #61? I have a suspicion, but I want to make sure I get this right. Nevermind, this seems to be a case of a stale lockfile (PID X is in it, but there is no PID X running). I'll have to think about this one. Adding more checks just makes the whole thing racier and racier. I think I have an admittedly ugly solution in commit f97ae47b8a4dd7b4959a019adf148390e3a182cf, aka -r3. (In reply to Tobias Klausmann from comment #9) > I think I have an admittedly ugly solution in commit > f97ae47b8a4dd7b4959a019adf148390e3a182cf, aka -r3. I'm still intermittently seeing the same message (same line, 61) on -r3 unfortunately. (In reply to candrews from comment #10) > (In reply to Tobias Klausmann from comment #9) > > I think I have an admittedly ugly solution in commit > > f97ae47b8a4dd7b4959a019adf148390e3a182cf, aka -r3. > > I'm still intermittently seeing the same message (same line, 61) on -r3 > unfortunately. I switched the lines to using sed, so we can redirect the error message cleanly. Version -r4 should fix this once and for all. (In reply to Tobias Klausmann from comment #11) > (In reply to candrews from comment #10) > > (In reply to Tobias Klausmann from comment #9) > > > I think I have an admittedly ugly solution in commit > > > f97ae47b8a4dd7b4959a019adf148390e3a182cf, aka -r3. > > > > I'm still intermittently seeing the same message (same line, 61) on -r3 > > unfortunately. > > I switched the lines to using sed, so we can redirect the error message > cleanly. Version -r4 should fix this once and for all. -r4 made the problem worse. Now every time I get multiple instances of this message: /usr/sbin/run-crons: line 61: warning: command substitution: ignored null byte in input Can you try replacing the \0 on lines 61 and 62 with \x0 and see if that fixes it for you? \x0 works for me... but just a thought... if diff -qs /proc/{${cronpid},$$}/cmdline > /dev/null ; then Is that easier than trying to get sed to fix the problem? (In reply to Dan Goodliffe from comment #14) > \x0 works for me... but just a thought... > > if diff -qs /proc/{${cronpid},$$}/cmdline > /dev/null ; then > > Is that easier than trying to get sed to fix the problem? That is an an excellent idea. I will do some tests tonight and use diff if that goes swimmingly. I put Dan's suggestion in -r5 -- thanks again! candrews: does this fix matters for you? (In reply to Tobias Klausmann from comment #13) > Can you try replacing the \0 on lines 61 and 62 with \x0 and see if that > fixes it for you? This change fixes the problem for me. Woo hoo! (In reply to Tobias Klausmann from comment #15) that syntax is a bash extension. we also don't want to rely on diff or cmp because those are provided by diffutils rather than more basic/common packages. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b11e8d8b4555479dce4054aca1feffb06c0066e6 |