Processing will not start for second user (or more) on a multiuser classroom computer.

[processing-bot]

Created by: Sewanee-raval

Description

Processing will not start for anyone except the first user in a multiuser classroom Ubuntu computer.

Expected Behavior

Processing will start and run as normal.

Current Behavior

students execute processing, either from an command line or from an icon.
First student on a computer has no problems using processing all features work.
Second student (or more) logs into the computer, executes processing and gets an error.
The first is a popup which actually describes what causes the error:

The second error can be see if processing is executed from the command line. If executed from an shortcut then the error below is hidden.

Exception in thread "Contribution List Downloader" java.lang.NullPointerException: Cannot invoke "java.util.List.iterator()" because the return value of "processing.app.Base.getToolContribs()" is null
at processing.app.contrib.ContributionListing.countUpdates(ContributionListing.java:348)
at processing.app.contrib.ContributionListing.lambda$downloadAvailableList$1(ContributionListing.java:227)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Steps to Reproduce

1. from the command line execute processing as user#1
   student01@owen: ~$ processing
   student01 can use processing as normal
2. from the command line execute processing as user#2
   student02@owen:~$ processing
   student02 gets error popup about not being able to create /tmp/processing/
3. Hit enter and student02 gets the error message about "Contribution List Downloader"

Your Environment

• Processing version: 4.0.1
• Operating System and OS version: Ubuntu Linux 22.04 LTS Desktop
• Other information: Users are authenticated to an Active Directory Domain server and their home directories are mounted via NFS / SSHFS. The classroom that they are using has 20+ computers and all of them show the same issue.

Possible Causes / Solutions

The issue is caused by the software creating a 'processing' directory in the /tmp folder and then not removing the directory
This can be seen after student01 uses processing and exits the program (and logs out of their profile).

1. change directory to /tmp
2. ls -la
   drwxr-xr-x student01 domainuser 4096 Sep 08 09:56 processing
3. cd into processing directory and it show temp sketchbooks that processing has created during its launch

The permissions are limited to student01 who has full control over the directory.
All other users are limited to read and execute permissions only, no write permissions.

The sketchbook settings in the preference file are set to /home/student01/sketchbook

It appears that processing is not cleaning up the /tmp/processing folder like it does the other files that it creates in /tmp and thus additional users can not use processing because the permissions on the folder are preventing their use.

4. If I delete the /tmp/processing folder any student can use processing again however it reverts to the same issue just with the new userid.

[processing-bot]

Created by: benfry

Hm, that's unfortunate that the default tmp folder used by Java on Ubuntu seems to be something global rather than per-user. Will look into a fix for 4.0.2.

[processing-bot]

Created by: benfry

In the meantime, you could probably also edit the processing shell script to add something like:

-Djava.io.tmpdir=/tmp/$USER

so the last line of that script would read:

java -Djava.io.tmpdir=/tmp/$USER -Djna.nosys=true -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -Dpython.console.encoding=UTF-8 -Xmx512m --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED processing.app.ui.Splash "$@" &

[processing-bot]

Created by: Sewanee-raval

Thank you. Your recommendations for the addition of the tmpdir directive to
the processing script has taken care of an individual locking out other
users. We have tested it and the students are using it with no problem.

On Fri, Sep 23, 2022 at 3:26 PM Ben Fry @.***> wrote:

In the meantime, you could probably also edit the processing shell script
to add something like:

-Djava.io.tmpdir=/tmp/$USER

so the last line of that script would read:

java -Djava.io.tmpdir=/tmp/$USER -Djna.nosys=true -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -Dpython.console.encoding=UTF-8 -Xmx512m --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED processing.app.ui.Splash "$@" &

—
Reply to this email directly, view it on GitHub
#549 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZETVIKPJE4YA5HTPVIZO43V7YHABANCNFSM6AAAAAAQH4MTWY
.
You are receiving this because you authored the thread.Message ID:
@.***>

--

Raymond Val

Linux System Administrator

Strategic Digital Infrastructure

Sewanee: The University of the South

Phone: 931.598.1335

Email: @.***

[processing-bot]

Created by: benfry

Fixed for 4.0.2, thanks for the report!

This was a regression caused by the changes to improve temp folder handling #529 which I finally fixed in 4.x, but had been an issue since 2013.

[processing-bot]

Created by: benfry

Also, perhaps you can report back on how things go with the temp directory cleaning process goes… For folders that are 7 days old (or temp.days as set in preferences.txt), the PDE will attempt to remove unused folders. However, detecting that these come from other users is especially tricky.

So if this original issue is something that was giving you trouble, please let me know if it behaves strangely when it tries to remove old temporary files. At worse, it may throw exceptions about not being able to delete certain files. More likely, it may fail silently if trying to remove older files created by another user (which would be ok), or it may put some red text in the console that it couldn't remove the folder.

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.