Correction

The problem is self-correcting with respect to the structure of the scheduling tree since the kernel attaches the lnode to the root lnode. Because the attachment is from an arbitrary point in the loop, the administrator has to determine where the lnode should be attached and also check the point of attachment for every other member in the loop.

The result of automatic group loop repair can be seen by listing the lnodes that are children of the root lnode. The command:

% limreport 'sgroup==0' - uid lname

will list all lnodes that have the root lnode as their parent. If any lnodes are listed that should not be children of the root lnode, they are possibly the top of a group loop that has been attached beneath the root lnode.

The major concern for the administrator when a group loop is detected is that, since the cause of the group loop was corruption to the limits database, many more serious problems could arise. If the administrator suspects corruption in the limits database, it is best to carry out some validation checks against the file to determine if it has been corrupted and then take remedial action. Refer to Crash Recovery for details on detecting and correcting a corrupt limits database.