Running dxp for the VORTEX on RHEL8 needs "umask 0"

[timmmooney]

Running dxp for the VORTEX detector (Handel library) required "umask 0" before starting the soft-linux IOC on RHEL8. Otherwise the IOC had the following complaint:

xiaInit("saturn.ini") xiaStartSystem [ERROR] 2021-10-05 13:11:31,652 xiaFddGetFirmware (fdd.c:299) : [ 1] Error opening the temporary file: /tmp/xia8398641bd91833148d227ddb6b325a1af92004f8

The reason, I'll guess, is that some Handel code is executed by the USB driver, and needs write access to the /tmp/xia* file which is created by the account running the IOC, but doesn't get it because of file permissions.

[MarkRivers]

The reason, I'll guess, is that some Handel code is executed by the USB driver, and needs write access to the /tmp/xia* file which is created by the account running the IOC, but doesn't get it because of file permissions.

No, that file is written and then read by the XIA Handel library, not by the USB driver. Does the file actually get created? If so can you send the output of "ls -l" on that file?

[timmmooney]

The file does get created, but the entity that later tries to open it fails apparently because the file permissions are rw_rw_r. Changing the file permissions to rw_rw_rw allows the IOC to finish booting.

Tim Mooney @.***) (630)252-5417 Beamline Controls Group (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab

---

From: Mark Rivers @.> Sent: Tuesday, October 5, 2021 5:28 PM To: epics-modules/dxp @.> Cc: Mooney, Tim M. @.>; Author @.> Subject: Re: [epics-modules/dxp] Running dxp for the VORTEX on RHEL8 needs "umask 0" (#6)

The reason, I'll guess, is that some Handel code is executed by the USB driver, and needs write access to the /tmp/xia* file which is created by the account running the IOC, but doesn't get it because of file permissions.

No, that file is written and then read by the XIA Handel library, not by the USB driver. Does the file actually get created? If so can you send the output of "ls -l" on that file?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/epics-modules/dxp/issues/6#issuecomment-934945764, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABT6PF6AVRWDS6G25HWGRKDUFN3YRANCNFSM5FMVDJGQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[MarkRivers]

What does ls -l show as the owner and group of the file? Since I think this code works on older Linux versions I suspect it is a change in security settings for /tmp on RHEL 8?

[MarkRivers]

The code that is generating the error is this:

    ofp = xia_file_open(completePath, "w");

    if (ofp == NULL) {
        sprintf(info_string,"Error opening the temporary file: %s", completePath);
        xiaFddLogError("xiaFddGetFirmware", info_string, XIA_OPEN_FILE);
        xia_file_close(fp);
        fdd_md_free(completePath);
        return XIA_OPEN_FILE;
    }

Note that the file is opened for write ("w"). xia_file_open just calls fopen(file, mode). That is creating a temporary file containing the firmware. That firmware is then later opened in saturn.c line 908 to read the firmware.

    /*
     *  Check to see if FiPPI configuration has already been read in: 0 words
     *  means it has not...
     */
    if ((fp = xia_find_file(fippi->filename,"r"))==NULL) {
        status = DXP_OPEN_FILE;
        sprintf(info_string,"%s%s","Unable to open FPGA configuration ",
                fippi->filename);
        dxp_log_error("dxp_get_fpgaconfig",info_string,status);
        return status;
    }

But that is not where it is crashing, it is crashing when writing the file.

I suggest changing the st.cmd to set the logging level to 4

# Initialize the XIA software
# Set logging level (1=ERROR, 2=WARNING, 3=XXX, 4=DEBUG)
xiaSetLogLevel(4)

[timmmooney]

I tried to reproduce the error with xiaSetLogLevel(4), but it's behaving differently today. John Freeland claims it behaves differently without beam (there is no beam today). I'm not familiar enough with the detector to guess what we need to do to reproduce the /tmp file problem we saw repeatedly last week.