>>>>> "BR" == Brian Reichert <[email protected]> writes:
BR> I have a perl app that daemonizes itself. Among it's daemonizing BR> efforts, it closes all file handles. BR> My app currently utilizes a third-party perl module, which in turn BR> makes use of the DATA file handle, as described in perldata(1). BR> (For all my years of using perl, this was the first I ran into this BR> mechanism, so it took a while to track down why this perl module BR> was misbehaving.) why are you concerned about closing the DATA handle? it is internal to the program. actually it is the handle the perl binary uses to read the source file and it is left at the seek point where the DATA starts. BR> The upshot is, when I used POSIX::close to close all file descriptors, BR> somehow the DATA descriptor remained alive: BR> - It was defined. BR> - I could retrieve a file descriptor via fileno(). BR> - I could use seek() and tell() to get/set my filepos. BR> Only stat() seemed to report that there was something was amiss. well, perl keeps it open so it can be used by anyone reading from DATA. you can check for it specially with some code i got from someone. it is special in that it is NOT tainted while all other handles are. this list (as most other rightly do) filters out attachments. so you should just paste your code in the email instead. but again, my question is why do you want to close the DATA handle? it shouldn't affect daemonizing. in general, you only would need to close the handles attached to the controlling terminal (stdio) and possibly do a double fork. many daemons use handles to write log files, read config files, communicate with sockets, etc. uri -- Uri Guttman ------ [email protected] -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
