Bug 1260300 - lsof binary is installed in /usr/sbin instead of /usr/bin
lsof binary is installed in /usr/sbin instead of /usr/bin
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lsof (Show other bugs)
rawhide
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Schiffer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-05 15:48 EDT by Jetchko Jekov
Modified: 2016-08-01 06:45 EDT (History)
2 users (show)

See Also:
Fixed In Version: lsof-4.89-2.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-30 07:46:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jetchko Jekov 2015-09-05 15:48:23 EDT
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 07:46:27 EST
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 07:47:11 EST
Koji build: http://koji.fedoraproject.org/koji/buildinfo?buildID=702302
Comment 3 Harald Reindl 2016-08-01 05:44:02 EDT
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 06:24:31 EDT
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 06:29:59 EDT
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 06:38:04 EDT
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 06:45:52 EDT
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

Note You need to log in before you can comment on or make changes to this bug.