Bug 209876 - backtrace on socket
Summary: backtrace on socket
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpmlint
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-07 10:24 UTC by Patrice Dumas
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 0.78-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-15 14:04:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Handle/mask errors in istextfile() (416 bytes, patch)
2006-10-09 19:54 UTC, Ville Skyttä
no flags Details | Diff

Description Patrice Dumas 2006-10-07 10:24:41 UTC
Description of problem:

Backtrace running rpmlint on installed package with socket in 
/var/run. The file exists:
# ls -l /var/run/fcron.fifo 
srw-rw-rw- 1 root root 0 Oct  7 10:26 /var/run/fcron.fifo


$ rpmlint fcron
W: fcron ldd-failed /usr/bin/fcronsighup
E: fcron non-standard-uid /usr/bin/fcrontab fcron
E: fcron non-standard-gid /usr/bin/fcrontab fcron
E: fcron setuid-binary /usr/bin/fcrontab fcron 06755
E: fcron setgid-binary /usr/bin/fcrontab fcron 06755
E: fcron non-standard-executable-perm /usr/bin/fcrontab 06755
Traceback (most recent call last):
  File "/usr/share/rpmlint/rpmlint.py", line 268, in ?
    main()
  File "/usr/share/rpmlint/rpmlint.py", line 92, in main
    runChecks(pkg)
  File "/usr/share/rpmlint/rpmlint.py", line 149, in runChecks
    c.check(pkg)
  File "/usr/share/rpmlint/FilesCheck.py", line 592, in check
    if istextfile(path):
  File "/usr/share/rpmlint/FilesCheck.py", line 232, in istextfile
    s=open(f).read(512)
IOError: [Errno 6] No such device or address: '///var/run/fcron.fifo'


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

rpmlint-0.78-1.fc6

How reproducible:

always with fcron, I haven't found another package owning a special
file.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ville Skyttä 2006-10-09 19:54:02 UTC
Created attachment 138067 [details]
Handle/mask errors in istextfile()

Hm, rpmlint trusts the rpm header when determining which type of file it is
examining, and apparently in this case the socket is listed as a normal file in
the package header.

That combined with the fact that there's no error checking in intextfile()
makes this a rpmlint bug indeed (to which the attached patch could be an
adequate bandaid for now - let me know if it changes anything), but I wonder if
the socket could be somehow listed as a socket in the fcron package header?  Is
there a way to create dummy sockets for %ghosting purposes during eg. %install?

Comment 2 Patrice Dumas 2006-10-10 06:42:04 UTC
The patch fixes the backtrace.

The socket is indeed listed as a normal file, since there is:

# rpmbuild insist that %ghost files exist?
%{__install} -d %{buildroot}%{_localstatedir}/run/
touch %{buildroot}%{_localstatedir}/run/fcron.pid
touch %{buildroot}%{_localstatedir}/run/fcron.fifo

and

%ghost %{_localstatedir}/run/fcron.pid
%ghost %{_localstatedir}/run/fcron.fifo


Maybe rpm insists that the file exists to record the correct type 
and perms and so on... But I don't know how to do a socket from
a shell script... 

Comment 3 Jeff Johnson 2006-10-10 11:57:23 UTC
Attempting to package sockets (and fifos and named pipes) is rather unnecessary: every daemon
that uses socket/fifo/pipe that I've ever seen creates the file system object, removing the old.

mknod(1) claims the ability to create a fifo.

The %dev() attribute marker in rpm could be extended to handle socket/fifo/pipe creation
if absolutely necessary. I personally think that packaging socket/fifo/pipe is a silly and
futile exercise, all those file system objects are meaningful/useful only within the scope of a
running daemon, and hence there is little need to package the objects.

No matter what, using touch and %ghost is really feeble hackery.

Comment 4 Patrice Dumas 2006-10-10 12:52:13 UTC
(In reply to comment #3)
> Attempting to package sockets (and fifos and named pipes) is rather
unnecessary: every daemon
> that uses socket/fifo/pipe that I've ever seen creates the file system object,
removing the old.
> 
> mknod(1) claims the ability to create a fifo.

There is also mkfifo.

> if absolutely necessary. I personally think that packaging socket/fifo/pipe is
a silly and
> futile exercise, all those file system objects are meaningful/useful only
within the scope of a
> running daemon, and hence there is little need to package the objects.

Yes, I agree with that. It seems that I added the socket,
I don't remember why, and indeed this seems a bit silly.
After some thinking packaging sockets seems really unfortunate.
Maybe I thought, based on the name, it was a fifo and not a 
socket and that it could remain after the daemon stopped.

For fifo it may theoretically make sense, these may be long lived 
objects and one may want to ensure that they are removed, and also that
they have correct permissions using rpm. In real life, this situation
is likely to be a packaging mistake however.

In the case of fcron it is clearly a packaging mistake I did.

> No matter what, using touch and %ghost is really feeble hackery.

It seems relevant to me to do that for pid file. It may make sense 
to have rpm remove stale pid files when removing package, especially 
if a directory containing the pidfile remains otherwise. And I don't
know how to do that except by doing a touch and %ghost.

Comment 5 Ville Skyttä 2006-10-10 20:00:41 UTC
A slightly improved version of the patch is applied upstream:
http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1285

(Whether or how to package some files is IMO better discussed on relevant 
mailing lists than here.)

Comment 6 Jeff Johnson 2006-10-10 22:46:50 UTC
Better than %ghost is a file with %verify(not md5 size mtime) because that identifies
the path as a file which %ghost does not.

Comment 7 Ville Skyttä 2006-10-15 14:04:20 UTC
Fixed in 0.78-2.fc*


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