Tinderd Bug - Tinderd killing wrong processes

[Joe Marcus Clarke]

On Thu, 2009-03-12 at 14:59 -0500, Tom Judge wrote:
> Joe Marcus Clarke wrote:
> > On Thu, 2009-03-12 at 14:23 -0500, Tom Judge wrote:
> >   
> >> Joe Marcus Clarke wrote:
> >>     
> >>> On Thu, 2009-03-12 at 12:15 -0500, Tom Judge wrote:
> >>>   
> >>>       
> >>>> Joe Marcus Clarke wrote:
> >>>>     
> >>>>         
> >>>>> <snip>
> >>>>>
> >>>>> What TB is trying to do is kill off processes that are holding a mount
> >>>>> point open.  In this case, the mount point
> >>>>> is /data/tinderbox/portstrees/mintel-6-2-mysql-5-0-51/ports.  Any
> >>>>> process which is using that directory is fair game.  I'm guessing you
> >>>>> started your jail from within that directory.
> >>>>>
> >>>>> As soon as the processes are dead, that directory gets unmounted, so
> >>>>> things would probably start to fail anyway.
> >>>>>
> >>>>> Joe
> >>>>>
> >>>>> <snip>
> >>>>>       
> >>>>>           
> >>>> I think the problem is that tinderd is being over zealous with the 
> >>>> killing of processes.  The sshd/cron/syslogd's are not in that 
> >>>> directory.  That directory is nullfs mounted off of:
> >>>>
> >>>> /data/ports/mintel-6-2-mysql-5-0-51
> >>>> <SNIP>
> >>>>
> >>>> And the ports tree definition:
> >>>>
> >>>> mysql>  select * from ports_trees where 
> >>>> ports_tree_name='mintel-6-2-mysql-5-0-51'\G
> >>>> *************************** 1. row ***************************
> >>>>          ports_tree_id: 1
> >>>>        ports_tree_name: mintel-6-2-mysql-5-0-51
> >>>> ports_tree_description:  FreeBSD 6.2 MySQL 5.0.51
> >>>>  ports_tree_last_built: 2009-02-12 16:59:41
> >>>>  ports_tree_update_cmd: USER
> >>>>  ports_tree_cvsweb_url: http://viewvc.mintel.co.uk/viewvc.cgi/mintelbsd/
> >>>> ports_tree_ports_mount: /data/ports/mintel-6-2-mysql-5-0-51
> >>>>     
> >>>>         
> >>> I don't think this is what you want.  If you set this column to NULL in
> >>> the database, I think this problem will go away.  Take a look at mine:
> >>>
> >>> mysql> select * from ports_trees where ports_tree_name = 'MarcusCom'\G
> >>> *************************** 1. row ***************************
> >>>          ports_tree_id: 2
> >>>        ports_tree_name: MarcusCom
> >>> ports_tree_description:  MarcusCom ports tree
> >>>  ports_tree_last_built: 2009-03-12 13:14:30
> >>>  ports_tree_update_cmd: USER
> >>>  ports_tree_cvsweb_url: http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/ports/
> >>> ports_tree_ports_mount: NULL
> >>> 1 row in set (0.00 sec)
> >>>
> >>> Joe
> >>>
> >>>
> >>>   
> >>>       
> >> Why would I set it to null?  I followed the example in the README for 
> >> using NullFS to mount the ports tree.
> >>     
> >
> > You only need to set this field to a non-NULL value if you are mounting
> > the ports tree from a different location onto your configured location
> > before beginning the port build.  This is typically a mount from a
> > remote host.  You don't need it for your configuration.
> >   
> 
> My ports tree is _not_ in 
> /data/tinderbox/portstrees/mintel-6-2-mysql-5-0-51/ports so I used the 
> example (From the README) to create a tree using an existing file system 
> (/data/ports/mintel-6-2-mysql-5-0-51) and nullfs. (PS my tinderbox base 
> is /data/tinderbox and the scripts folder is in /data/tinderbox/scripts).
> 
> If i set this field to null surely all my builds will fail as there is 
> no ports tree at the location its expecting:
> 
> itchy# ls -la /data/tinderbox/portstrees/mintel-6-2-mysql-5-0-51/ports/
> total 4
> drwxr-xr-x  2 root  wheel  512 Feb 12 16:36 .
> drwxr-xr-x  3 root  wheel  512 Feb 12 16:36 ..
> itchy#

Okay, I understand.  Most users who have configured this setting should
not have, and it causes them problems.  You seem to have a legitimate
config.

[snip]

> If my configuration is truly wrong I will fix it but I was just 
> following the documentation.
> 
> It seems switching to NFS should fix this issue as then the ports tree 
> will be a distinct file system from the rest of /data which should stop 
> the wrong things getting killed..

Yeah.  Lsof might be an option here, but that would require a dependency
on lsof which has a tendency to break on -CURRENT from time-to-time.
Does lsof report the correct process data for you?

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://marcuscom.com/pipermail/tinderbox-list/attachments/20090312/b373fb69/attachment.bin>