To be clear: while the "silent" part is annoying, the core problem is that gssproxy cannot handle duplicate section definitions.

This creates a situation where any package on the system can contribute an /etc/gssproxy/*.conf file that will cause gssproxy to die, by contributing a section that was already defined in another configuration file. There is no way to prevent or defend against this, because there is no way to prevent packages from dropping new files into the /etc/gssproxy directory.

Treating a duplicate section as a fatal error is acceptable iff there is a single, monolithic configuration file that can be controlled in totality by the administrator. Supporting multiple configuration files, while a helpful feature, necessitates a more intelligent strategy for handling duplicate sections.

I think this strategy makes the most sense:

• Read the /etc/gssproxy/gssproxy.conf.
• Read all other /etc/gssproxy/*.conf files, in lexical order.
• The first occurrence of a section is the one that is used; any subsequent occurrences generate a warning message that gssproxy is ignoring the duplicate.

Thoughts?

Sounds like a good way to deal with it, thanks @ralston

I don't know why the behavior of keeping going here is desirable. I would rather call out to the administrator that something is broken and force them to fix it.

I don't know why the behavior of keeping going here is desirable.

Because gssproxy is a critical component of our NFS and web infrastructures, and having it break arbitrarily on us, typically in the wee AM hours, in a manner we can neither predict nor prevent, is something we'd prefer to avoid.

I would rather call out to the administrator that something is broken

That's what warning/error log messages are for.

and force them to fix it [by refusing to run]

I will grant there are situations where refusing to run is preferable to attempting to run. For example, if data corruption is detected, and running is likely to worsen the data corruption, then refusing to run can be the best course of action, even though refusing to run can cause production outages and other breakage.

But this is not one of those cases. Having a duplication section name isn't a critical issue. In fact, just the opposite is true: because gssproxy has moved from a single monolithic configuration file to multiple configuration files, and because random packages can now contribute their own gssproxy configuration files, having two different sources attempting to define the same section is arguably an expected occurrence.

You do not haul system administrators out of bed at 04:00 (because half of the production infrastructure just broke) because of an expected occurrence. You log it so that it can be discussed during the next day's log review.

Robbie, I agree @ralston in this case. We can keep running by just ignoring the conflict and shouting loudly in the logs, so we should do it.

I don't think we're going to agree on this. I also don't care about this very strongly because I am an admin, so I defer.

Fixed in 2c44a2ded88990de44665ed297c135bec844d016