Bug 1260300

Summary: lsof binary is installed in /usr/sbin instead of /usr/bin
Product: [Fedora] Fedora Reporter: Jetchko Jekov <jetchko.jekov>
Component: lsofAssignee: Peter Schiffer <pschiffe>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: h.reindl, pschiffe
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: lsof-4.89-2.fc24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-30 12:46:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jetchko Jekov 2015-09-05 19:48:23 UTC
Description of problem:
lsof package install 'lsof' binary in /usr/sbin which makes it undiscoverable when non interactive scripts search $PATH for it.

Version-Release number of selected component (if applicable):

lsof-4.89-1.fc24.i686.rpm

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
'lsof' binary should be installed in /usr/bin. Its not system admin only utils anyway.

Additional info:

Comment 1 Peter Schiffer 2015-11-30 12:46:27 UTC
Fixed in lsof-4.89-2.fc24
http://koji.fedoraproject.org/koji/taskinfo?taskID=12015412

Thanks for the report.

Comment 2 Peter Schiffer 2015-11-30 12:47:11 UTC
Koji build: http://koji.fedoraproject.org/koji/buildinfo?buildID=702302

Comment 3 Harald Reindl 2016-08-01 09:44:02 UTC
that change was shortminded, you break every script using a absolute path

/sbin versus /bin is not about admin/non-admin - it was about static/non-static in case of /usr is a different filesystem that /root and /sbin which may not be mounted

anyways, /usr/sbin is in the PATH of everyone for years now and when it's not in some cases then these are bugs and needs to be fixed

[root@buildserver:~]$ distribute-needs-restart.sh 
Rufe Kommando '/usr/sbin/lsof | grep DEL | grep /usr' auf allen Maschinen auf

arrakis
bash: /usr/sbin/lsof: Datei oder Verzeichnis nicht gefunden

--------------------------------------------------------------------------

caladan
bash: /usr/sbin/lsof: Datei oder Verzeichnis nicht gefunden

--------------------------------------------------------------------------

thebe
bash: /usr/sbin/lsof: Datei oder Verzeichnis nicht gefunden

Comment 4 Jetchko Jekov 2016-08-01 10:24:31 UTC
I am sorry but /sbin have nothing to do with static/non-static binaries and definitely nothing to so with the split root case. I am sure you can do your own search but here it is anyway:

http://www.linfo.org/sbin.html

Besides [/usr]/sbin maybe is in the PATH for years but only when you have login shell. Thats not the case when you are executing something as non-root before login or in crontab.

I would also argue that scripts that are using absolute paths to non-core utils are broken. So better fix the scripts.

Comment 5 Harald Reindl 2016-08-01 10:29:59 UTC
as said: then you better have written bugreports for the pieces with the wrong PATH, on the over 30 systems i am responsible for that's fixed in /etc/crontab, /etc/anacrontab and so on for years and be it only to get the stupidity of "/bin:/usr/bin" which remained way too long after UsrMove away

Comment 6 Peter Schiffer 2016-08-01 10:38:04 UTC
Harald, I'm sorry for your broken scripts, but when working on this issue, the main reason why I did the switch was that other major distros (debian, arch, gentoo, suse), all have /usr/bin/lsof, so it did make sense to "align".

Are the scripts your own, or is there a package which needs to be updated?

peter

Comment 7 Harald Reindl 2016-08-01 10:45:52 UTC
own scripts, and that's the problem when you are working on a operating system - it's not a isolated world and it's whole purpose of existing is to run users code and applications and not olny to serve distribution packages right

the reason for using absolute paths is security and stability because you don't get trapped when some idiot has a shellscript with the same name in /usr/local/bin or even in his *writeable* homedirectory placed there by arbitary code and so you can be sure you are wroking with the correct command

frankly, such arbitary changes should install a symlink in the old location