Bug 225986 - sysutils/lsof false warning
Summary: sysutils/lsof false warning
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Rodney W. Grimes
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-17 13:58 UTC by Rodney W. Grimes
Modified: 2018-02-27 09:39 UTC (History)
7 users (show)

See Also:
bugzilla: maintainer-feedback? (ler)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-17 13:58:41 UTC
The binary package of lsof when installed on a binary updated FreeBSD 11.1-p6 system (userland 11.1-p4) erroniously compares 11.1-p4 to 11.1-p6 and gives the user a warning.

This is cause by a bad compiled in constant of 11.1-p6 is LSOF_VSTR,
the compiled in constant is obtained from uname -r in the file
Configure, I suggest changing this to uname -K -r.
Comment 1 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 14:00:09 UTC
This is by design.  There might be kernel changes that would cause issues with lsof.
Comment 2 Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-17 14:37:45 UTC
This is NOT by design, this is by not understanding that when users update there 11.1 system they end up with a user land of 11.1-p4 and a kernel of 11.1-p6 and when you build a binary package of lsof on the cluster it compiles in the wrong constant to compare!
Comment 3 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 14:39:27 UTC
lsof is sensitive to the KERNEL version.
Comment 4 Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-17 14:41:48 UTC
And there is NO SUCK KERNEL as 11.1-p6  DO NOT CLOSE THIS AGAIN.
Comment 5 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 14:44:45 UTC
please show me a uname -r and the exact error messages.

And are you complaining about a package built on the cluster or hand built?
Comment 6 Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-17 14:57:59 UTC
This is in regard to the packages built on the cluster and being installed on to an 11.1 system that has had binary updated.

No, I dont have any of the uname -r output anymore as I was helping someone with this issue in IRC.

I HAVE however looked at the port and src's enough to know that the way things are being built the code end up comparing the wrong two strings.

It is comparing the -U string to the -K string and failing, what appears to be due to the use of just "uname -r" in the Configure script.  If you replace that with "uname -K -r" it should fix it, and as you say it depends on the kernel version so we should STOP comparing userland version.
Comment 7 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 15:08:32 UTC
Ok, I'm spinning up a 11.1-REL VM, and will look.
Comment 8 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 15:30:28 UTC
I think the issue is that the build cluster jail lies on the uname -r, since a binary updated system shows 11.1-RELEASE-p4 on uname -r. 

Why does the build cluster give a different answer than a system doing binary upgrades?
Comment 9 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 15:42:42 UTC
I spun up a 11.1-RELEASE VM, freebsd-updated to -p6, and then built lsof on that machine and:

-DLSOF_VSTR="11.1-RELEASE-p4"

and:
# freebsd-version -u
11.1-RELEASE-p6
# freebsd-version -k
11.1-RELEASE-p4
#

To my mind, if the build cluster is using the RELENG/11.1 source tree, it should set UNAME_R to 11.1-RELEASE-p4

I don't think this is an lsof port issue.
Comment 10 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 15:43:08 UTC
clusteradm, what say you?
Comment 11 Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-17 16:13:01 UTC
(In reply to Larry Rosenman from comment #9)
I think installing the lsof pkg at this point rather than building it
from code would show you the error the end user is getting.

Perhaps your right in the cluster is building things with a
modified uname string, but why would its kernel report -p6
as there is no such kernel....

Thank you for sticking with me on this...
Comment 12 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 16:14:42 UTC
it does.  I think the build cluster(s) do the builds in a jail with a UNAME_R variable set in the environment. 

Hence, getting clusteradm@ involved (or should it be portmgr?)
Comment 13 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 16:29:04 UTC
Minor correction, the environment variable would be UNAME_r.  per uname(3) man page.
Comment 14 Adam Weinberger freebsd_committer freebsd_triage 2018-02-17 17:50:19 UTC
AFAIK, in general the clusters build all packages on a 12 box. It has no way of knowing what the kernel version is, as poudriere jails don't fetch or extract the kernel. In standard poudriere jails, "freebsd-version -k" produces an error about a missing kernel.

The best guess it can make is that kernel = host.
Comment 15 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 18:52:00 UTC
After an email exchange with adamw@, I've added a pkg-message to the sysutils/lsof port about this possibility.
Comment 16 commit-hook freebsd_committer freebsd_triage 2018-02-17 18:52:12 UTC
A commit references this bug:

Author: ler
Date: Sat Feb 17 18:51:17 UTC 2018
New revision: 462185
URL: https://svnweb.freebsd.org/changeset/ports/462185

Log:
  Add a pkg-message about pre-built binaries and kernels.

  PR:		225986
  Reviewed by:	adamw

Changes:
  head/sysutils/lsof/Makefile
  head/sysutils/lsof/pkg-message
Comment 17 Allan Jude freebsd_committer freebsd_triage 2018-02-17 19:07:55 UTC
This seems to miss the point.

Maybe it makes more sense to use uname -K, since that is the ABI version, and should change if the ABI changes. Or truncate the patch level off of the version string, since the ABI shouldn't change between 11.1-p4 and 11.1-p6.
Comment 18 Larry Rosenman freebsd_committer freebsd_triage 2018-02-17 19:09:17 UTC
It's the KBI, and source changes HAVE broken it before. 

I don't want to change the upstream check.
Comment 19 Adam Weinberger freebsd_committer freebsd_triage 2018-02-17 19:23:54 UTC
(In reply to Allan Jude from comment #17)

In a poudriere jail, uname -K will report the version of the host kernel. AFAIK, packages are built on -CURRENT hosts, so this check will always be wrong.
Comment 20 Adam Weinberger freebsd_committer freebsd_triage 2018-02-18 01:16:48 UTC
(In reply to Allan Jude from comment #17)

Shouldn't, but occasionally it does. It's better to have a warning message that things may be wrong than to have it actually be wrong with no warning.

uname -K is wrong in poudriere jails (it reports on the host kernel), and freebsd-version -k doesn't work at all in poudriere jails (there's no kernel installed in the jail).

AFAIK, there's no way to actually get this right. A pkg-message explaining the message is probably as universal as the solution can get. From my perspective, this can be closed.
Comment 21 Larry Rosenman freebsd_committer freebsd_triage 2018-02-18 01:23:15 UTC
closing per adamw@
Comment 22 Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-18 01:35:55 UTC
Really?  Closed 3 times without a resolution?

I'll take this, and get to the bottom of it.

I do not find false warnings that lead users a stray a good idea.

I also finding it appauling that the port built from src is fine,
but a pkg installed at the correct version is not.  This indicates
a reproducability issue at minimum.
Comment 23 Larry Rosenman freebsd_committer freebsd_triage 2018-02-18 01:37:16 UTC
Please do *NOT* change sysutils/lsof without my *EXPLICIT* approval.
Comment 24 Rodney W. Grimes freebsd_committer freebsd_triage 2018-02-18 01:55:51 UTC
(In reply to Adam Weinberger from comment #19)
I do not believe that packages are always built on current hosts, my understanding is that they are built on the oldest release of the supported branch, aka 11.x ports are built on an 11.1 system.

If that is not the case then the build environment needs enhanced so that both a UNAME_r and UNAME_K_r exist, the right things just happen.

(In reply to Larry Rosenman from comment #18)
I agree, there should not be a change to upstream, other than possibly in the FreeBSD specific portion of Configure where it deals with creating the LSOF_VSTR, but as you point out, this code does infact "DTRT" when compiled on an actual 11.1-p6 box, so this leads to the build environment is where the fix needs to be.

Larry, your marked as MAINTAINER in the Makefile, of cource I would seek your approval before any commit.


Glen, I am adding you to this so you can confirm, deny, clarify, or expand on where and in what environment the packages for FreeBSD 11.1-p6 are built?
Comment 25 Larry Rosenman freebsd_committer freebsd_triage 2018-02-26 16:14:37 UTC
Portmgr: Comments, please.
Comment 26 Allan Jude freebsd_committer freebsd_triage 2018-02-26 16:34:58 UTC
(In reply to Rodney W. Grimes from comment #24)
I believe packages are always built on a host running -current, but in a jail that has the oldest supported stable release of the branch in question installed. So the userland it is linking against is 11.x, the running kernel is 12-current. The environment is modified to trick the compilation process. It may be possible that one such environment variable is missing.

I think the source of the problem is likely that the 'version' reported via poudriere to the compilation process is that of the userland version, since there is no kernel, so in the slightly off freebsd-update case where you have a -p6 userland, but only a -p4 kernel because the kernel has not changed in -p5 or -p6, a freshly built package will produce the warning.
Comment 27 Mathieu Arnold freebsd_committer freebsd_triage 2018-02-27 09:39:02 UTC
This is an artifact of how poudriere builds things. It gets the version from the jail, which is 11.1-p6, and decides that it is what the version is.
Reading all the comments quickly, this was explained in comments 14, 20, 26.
This was already closed three times, so let's close it again.