search

nasa / osal

The Core Flight System (cFS) Operating System Abstraction Layer (OSAL)
Apache License 2.0
554 stars 216 forks source link

Cryptic failure when running CFS as non-root #300

Open BaldBeacon opened 4 years ago

BaldBeacon commented 4 years ago

When running the CFS without elevated privileges, the output that indicates an os failure doesn't express errors with scheduler policy. The current output under these conditions is:

CFE_PSP: Default Reset Type = PO
CFE_PSP: Default Reset SubType = 1
CFE_PSP: Default CPU ID = 1
CFE_PSP: Default Spacecraft ID = 42
CFE_PSP: Default CPU Name: cpu1
CFE_PSP: Starting the cFE with a POWER ON reset.
CFE_PSP: OS_API_Init() failure

The origin of this issue comes from https://github.com/nasa/osal/blob/155e9ebcd6d1930890231a44237e6883d229d22c/src/os/posix/osapi.c#L692

A failure to set the schedule policy should probably have a special error message indicating both why it failed and the recommended course of action.

jphickey commented 4 years ago

This is actually leaps and bounds better than what used to happen, where CFE startup would proceed and attempt to use uninitialized variables resulting in a crash/lockup. That's not to say it still couldn't be better.

There is a related issue about this in nasa/cFE#358, regarding making the "out of the box" config enable the permissive modes so as to not require root.

Note that the is an OS_DEBUG message regarding the failure of setschedparam, but this also isn't displayed unless OS_DEBUG_PRINTF is defined, so one would not see this either.

One possibility might be to move this issue over to nasa/PSP where some additional printf's can be performed, suggesting common failure resolutions here (i.e. either run as root or ensure permissive mode is turned on).