wobbleian wrote:

>
> In the comments from Ubuntu we have some source code differences to
> the regular release including:
>
> * For classic, fb_lock_mgr, the lock manager, is built with
> -DTERMINATE_IDLE_LOCK_MANAGER option to avoid leaving stale processes
> on build machines. This option causes fb_lock_mgr to terminate after
> 5 minutes of inactivity.
>
> However, even with activity we get the segfault every 5 minutes.
>
> This is currently being observed on a development server, but its twin
> was installed last month as a production server due to go live asap
> and it is showing the same symptoms.
>
> I havent been able to confirm if this is causing any other problems -
> we are currently testing this with "select cast('now' as timestamp)
> from rdb$database;" and the query always succeeds.

The fb_lock_mgr is slightly misnamed. The actual management of the
lock table is done cooperatively by all processes attached to firebird
databases. However, in ancient times, several Unix type systems
considered it a security violation to signal between process groups.
When a process waits for a lock, it's actually waiting for a signal
that the lock has been released. If two processes contending for a
lock were in different process groups, the waiting process was never
alerted that the lock was now free. The fb_lock_mgr is a process
with setuid that can forward signals across groups. When each
process could belong to only one group, that was important. And,
typically, the problem showed up only after an application went
into production.

Now, the reasonable solution is to have all firebird processes
belong to the firebird group, and not use fb_log_mgr.

>
> Should I be worried about this?

Yes, it's ugly.

>
> Should I be raising this on an Ubuntu forum?

Yes, I think so.


Regards,


Ann