I''m trying to install the tomcat5.5 package under Debian Etch. The problem is that the init.d script for tomcat5.5 uses "su .... &" to run some things (I think logging processes?) This causes puppetd to hang in its run, because the subprocess never returns (due to open filehandles?). Does anybody have any idea what I can do to get around this? The same "hanging" occurs if you manually run the init script from an ssh session, and then log out. Ssh doesn''t die, and you have ~. to get out. Thanks, Jordan
Jordan Share <jshare@krotus.com> writes:> I''m trying to install the tomcat5.5 package under Debian Etch.> The problem is that the init.d script for tomcat5.5 uses "su .... &" to > run some things (I think logging processes?) This causes puppetd to > hang in its run, because the subprocess never returns (due to open > filehandles?).> Does anybody have any idea what I can do to get around this?> The same "hanging" occurs if you manually run the init script from an > ssh session, and then log out. Ssh doesn''t die, and you have ~. to get > out.First, I would file a bug against the Debian package. Second, if you can track down what file descriptors are being left open using lsof (and include this information in the Debian package), you can sometimes work around problems like this by modifying the init script to redirect those file descriptors to something other than standard input, output, and error. Strategically using >/dev/null, 2>/dev/null, or </dev/null when running the commands will usually work. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Mar 15, 2007, at 11:30 PM, Russ Allbery wrote:> Jordan Share <jshare@krotus.com> writes: > >> I''m trying to install the tomcat5.5 package under Debian Etch. > >> The problem is that the init.d script for tomcat5.5 uses "su .... >> &" to >> run some things (I think logging processes?) This causes puppetd to >> hang in its run, because the subprocess never returns (due to open >> filehandles?). > >> Does anybody have any idea what I can do to get around this? > >> The same "hanging" occurs if you manually run the init script from an >> ssh session, and then log out. Ssh doesn''t die, and you have ~. >> to get >> out. > > First, I would file a bug against the Debian package. > > Second, if you can track down what file descriptors are being left > open > using lsof (and include this information in the Debian package), > you can > sometimes work around problems like this by modifying the init > script to > redirect those file descriptors to something other than standard > input, > output, and error. Strategically using >/dev/null, 2>/dev/null, or > </dev/null when running the commands will usually work.I''d *love* to get this fixed in the painfully-soon 0.22.2 release, if anyone has any recommendations on how to do tos. -- Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies <luke@madstop.com> writes:> On Mar 15, 2007, at 11:30 PM, Russ Allbery wrote:>> Second, if you can track down what file descriptors are being left open >> using lsof (and include this information in the Debian package), you >> can sometimes work around problems like this by modifying the init >> script to redirect those file descriptors to something other than >> standard input, output, and error. Strategically using >/dev/null, >> 2>/dev/null, or </dev/null when running the commands will usually work.> I''d *love* to get this fixed in the painfully-soon 0.22.2 release, if > anyone has any recommendations on how to do tos.Well, I''m not sure that it''s properly your problem. Other systems that do what Puppet does have the same issue, and the correct course of action is for daemons to not leave behind random open file descriptors. However, that being said, the way to work around this is to not simply block waiting on output until the file descriptor from a subprocess is closed. Instead, you have to reap children each time that SIGCHLD knocks you out of the select loop, harvest them with waitpid, and once the process you spawned has exited, close your end of the pipes even if you haven''t gotten any input and consider that good enough. The most likely cause of this issue is that you''re blocking forever waiting on EOF even though the child that you originally spawned has itself exited. But really, the init script or the application should be fixed, since often the application doesn''t like a closed standard output either. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Mar 15, 2007, at 10:34 PM, Jordan Share wrote:> I''m trying to install the tomcat5.5 package under Debian Etch. > > The problem is that the init.d script for tomcat5.5 uses "su .... > &" to > run some things (I think logging processes?) This causes puppetd to > hang in its run, because the subprocess never returns (due to open > filehandles?). > > Does anybody have any idea what I can do to get around this? > > The same "hanging" occurs if you manually run the init script from an > ssh session, and then log out. Ssh doesn''t die, and you have ~. to > get out.I had the same problems. If you read the bugs for that package you''ll see a lot of discussion about it. I believe they''re going to use jsvc in the next packages, so I just rewrote the init script to use jsvc and my problems are gone. I''d post the script but it''s got a lot of customizations for our specific application. jsvc is very straight-forward to use though. The only oddity is that sometimes it returns an exit code of 1 when tomcat starts just fine... haven''t figured that one out yet. -Blake