Any specific reason that routed daemon is 32-bit in a 64-bit system?

[kamilazat]

Hello everyone.

We have an open TAC ticket going on for investigation of a persistent memory leak of routed daemon due to OSPF. Even enabling debugging for routed daemon for 'Global' didn't provide much information. And so far, the port fixes provided by R&D didn't help, but they are investigating nevertheless.

During our conversations with TAC I asked which kinds of analyses are being done. Maybe valgrind or strace or something. In their response they mentioned that routed daemon is a 32-bit process, which makes it difficult to analyze the behavior of rotued, especially in a production environment. So I understand that it can be dangerous and requires in-house replication.

What I don't understand/know is why routed daemon is 32-bit even though the kernel is 64-bit. Probably this is an ignorant question but it bugs me as much as OSPF bugs routed. I'm sure there's a good reason to keep it 32-bit, so maybe someone can illuminate me on it.

One potential idea that came to my mind is that routed daemon contains old, complex routing protocol implementations that may have been originally developed for 32-bit systems. But nothing is due to only one reason, so I'm sure there's more to it than I see.

Thank you in advance.

Cheers!

[PhoneBoy · Accepted solution]

While the OS kernel has been 64-bit only since R80.10, there are several userspace processes that are still 32-bit.
This includes Check Point-specific code (i.e. not components you'd find in RHEL) and/or have specific integrations with Check Point-specific code (ClusterXL and routed, for instance).

Over time, I presume we will upgrade everything to 64-bit.

[the_rock]

I actually verified the same in R82, but what @PhoneBoy said is the same answer I got recently from TAC.

Andy