Unhandled exception in web app as non root user

Targets Web
1

Not sure whether this is a Web question or a Linux question.

I’ve created a web app using Xojo 2020r2.1 and after rolling out am getting trouble from a list box.

When I run the app as a non root user I get an unhandled exception. Copied below.
The app is self contained and the fault appears to be caused by populating a list box.
The list box appears empty in the browser.

When I run the app as a root user all is well.

Anyone know what I need to grant to the non-root user to avoid the exception.

Linux version info

Linux 5.10.0-28-686-pae #1 SMP Debian 5.10.209-2 (2024-01-31) i686 GNU/Linux
$ cat /etc/debian_version 11.9

Exception info

Unhandled error 
Message: 
Number: 2
Reason: 
Stack: 
BinaryStream.!Create%o<BinaryStream>%o<FolderItem>b
_WebFileBuffer.Constructor%%o<_WebFileBuffer>o<FolderItem>
_WebFileBuffer.Constructor%%o<_WebFileBuffer>
WebResponse.Write%%o<WebResponse>s
WebSession._HandleRequestForData%i4%o<WebSession>so<_HTTPServer.HTTPRequestContext>
WebSession._HandleRequest%i4%o<WebSession>so<_HTTPServer.HTTPRequestContext>
WebApplication._HandleHTTPRequest%%o<WebApplication>o<_HTTPServer.HTTPRequestContext>
_HTTPServer.HTTPRequestThread.Event_Run%%o<_HTTPServer.HTTPRequestThread>

End of stack
2

Your Stack mentions BinaryStream, Create, and FolderItem, maybe the webapp is trying to create a file/folder where it doesn’t have rights to write?

1 Like
3

Unless the web app is trying to use privileged ports it arguably should not require root user. This doesn’t read like its related to listening ports…

My preference would be that you create a new issue to report this as a bug so that it can be fixed.

As a workaround, double check that the user you are running with can write into the temporary location. If not, pass an --UploadPath you can write to. With Lifeboat use the “Manage --UploadPath” switch on the Options tab to do so with one click.

4

Just as a follow up to clarify my line of thought:

  • The _ underscore prefix means it’s an internal framework method / class
    • Xojo is consistent about this practice
  • _HandleHTTPRequest means it’s within the Web App Framework’s HTTP handler
    • Outside of any of our code in a web project
    • Means we cannot catch this exception and correct
      • Only option is to work around
    • Needs to be fixed in the framework
  • _WebFileBuffer seems like it could be related to temporary files (*speculation)
    • --UploadPath argument docu mentions “or other large requests”
    • Possible diagnosis: Large request or response needing a temporary file & temporary not writable

The documentation for BinaryStream.Create also has a note that seems relevant:

If the stream can not be opened as requested, an IOException will be raised. For instance, this will happen if the file is already opened for writing, or if the app (its user) has no permission to modify this file or to create a file in the affected directory.

1 Like
5

Not speculation. The http backend automatically creates a buffer in memory for small payloads and on disk for large payloads. Binary streams are used in both cases for compatibility, flexibility and speed. By default, they are created in the tmp directory.

Here’s what I suggest, go to the tmp directory on the machine and check to see if the temp files for Xojo are put in a folder and if so, what the permissions are. If the owner and group are set to root:root, change the permissions on the folder so that anyone can read, write & execute with:

chmod 777 <Xojo temp dir>

I just can’t remember off the top of my head and it’s too late to check

2 Likes
6

Thanks @Greg_O and @Tim_Parnell for providing the clues to track down the issue.

The framework is creating a directory in /tmp with the listening port number prefixed by an underscore.
Eg. /tmp/_8080
When the process is terminated this folder is not deleted.

After uploading the app to the server I originally tested it using sudo. So, the _8080 directory was created by root. When I restarted as a normal user the process lacked the permission to write to the _8080 directory. The fix is simply to delete the _8080 directory and allow the framework to recreate it when the web app is started.

Some additional details which may or may not be related.
The web app is being started with nohup.
The web app uses an Audio Player control. As far as I can tell the _8080 folder is created when the audio file is retrieved from it’s URL.

7

I suggest using SystemD instead so if the app crashes, hangs or quits it can be automatically restarted.

8

Understood.

The app is a quick and dirty bit of fluff. Nothing I want starting automatically with the server. It won’t last long enough for the certificate to be renewed.

It’s a learning tool to help me with an amateur radio exam I’ll be taking in a month or so. Feel free to take a look. qcodes dot emsnet dot uk

1 Like