Cleanup of /tmp seems INOP - Kubuntu 20.04

Development Tools IDE 2.x
1

arduino-ide_nightly-20230101_Linux_64bit

It looks like the IDE is not cleaning up the /tmp folder entries. Did I miss a setting or are others seeing this kind of left-over stuff in /tmp?

$ls /tmp | grep arduino

arduino-core-cache
arduino-ide2-02452aa76834037eb1984e1166b9365e
arduino-ide2-0dbf056a82589d4e68b454aae9921daf
arduino-ide2-486ac0bf5a54ba5bab4eb0b11eb5f9e8
arduino-ide2-a29a7049194a10904af761c3170b1f39
arduino-ide2-a2ac30869331fb2e1b2f119038a85f17
arduino-ide2-a39d91dc8d78b28e5212e8be05dfe3d8
arduino-ide2-abb516e60e972a8bc0dc9fdb13f8acb2
arduino-ide2-b3b2b9b9b709e9ef595598fed45a1474
arduino-ide2-e089a9c7017830d067eb8eb871eaa1a0
arduino-language-server1017969974
arduino-language-server1023789792
arduino-language-server1070295057
arduino-language-server1108686230
arduino-language-server1133590230
arduino-language-server1135479087
arduino-language-server1199143388
arduino-language-server1207015129
arduino-language-server1230364521
arduino-language-server1266537642
arduino-language-server1344567102
arduino-language-server150285455
arduino-language-server1550180006
arduino-language-server1563828080
arduino-language-server1571027164
arduino-language-server1575976061
arduino-language-server1592794705
arduino-language-server1606235881
arduino-language-server161055157
arduino-language-server1610601276
arduino-language-server1619625479
arduino-language-server1650417237
arduino-language-server1656991740
arduino-language-server1658966248
arduino-language-server1668372227
arduino-language-server167031
arduino-language-server175630275
arduino-language-server1790927509
arduino-language-server1806757279
arduino-language-server1810508894
arduino-language-server1811890480
arduino-language-server1816673027
arduino-language-server1841991332
arduino-language-server1849079866
arduino-language-server1855600802
arduino-language-server1865851461
arduino-language-server18941142
arduino-language-server1903029744
arduino-language-server1904151999
arduino-language-server1952182432
arduino-language-server1959539184
arduino-language-server1987330968
arduino-language-server2030363202
arduino-language-server2049713758
arduino-language-server2073182930
arduino-language-server2083505767
arduino-language-server2121346962
arduino-language-server2127408855
arduino-language-server2155276676
arduino-language-server2249661221
arduino-language-server2249790705
arduino-language-server2274020556
arduino-language-server2281374138
arduino-language-server2389617225
arduino-language-server2449532044
arduino-language-server2524106522
arduino-language-server2524228661
arduino-language-server2558817403
arduino-language-server2575083828
arduino-language-server2606147102
arduino-language-server2609604229
arduino-language-server2643885937
arduino-language-server2662080669
arduino-language-server2667252857
arduino-language-server2668782828
arduino-language-server2671044239
arduino-language-server2712070057
arduino-language-server2712724405
arduino-language-server2721412747
arduino-language-server2736688092
arduino-language-server2744970172
arduino-language-server2761177619
arduino-language-server2784329615
arduino-language-server2820287501
arduino-language-server2829183806
arduino-language-server2836102169
arduino-language-server2842628351
arduino-language-server2864950180
arduino-language-server2909884216
arduino-language-server2913428076
arduino-language-server2925643535
arduino-language-server2945396555
arduino-language-server2953518249
arduino-language-server2961034387
arduino-language-server2966953445
arduino-language-server2987071808
arduino-language-server2987491063
arduino-language-server3009998375
arduino-language-server3060586500
arduino-language-server3071193693
arduino-language-server307322360
arduino-language-server3087150139
arduino-language-server313785093
arduino-language-server3138736763
arduino-language-server314818150
arduino-language-server3152585344
arduino-language-server3177866347
arduino-language-server3183362446
arduino-language-server323460272
arduino-language-server3271523874
arduino-language-server3277327810
arduino-language-server329685728
arduino-language-server3298790142
arduino-language-server3368428508
arduino-language-server3382174858
arduino-language-server3406415816
arduino-language-server3412478244
arduino-language-server342281034
arduino-language-server3422913140
arduino-language-server3437755037
arduino-language-server3442561031
arduino-language-server3442888695
arduino-language-server3465023737
arduino-language-server3474544701
arduino-language-server3484095995
arduino-language-server3484718922
arduino-language-server350077979
arduino-language-server3554391129
arduino-language-server3581506044
arduino-language-server3605364197
arduino-language-server3609492267
arduino-language-server3639117004
arduino-language-server3641126725
arduino-language-server3679007989
arduino-language-server3711834217
arduino-language-server3742442776
arduino-language-server3745624716
arduino-language-server3761781043
arduino-language-server3807165172
arduino-language-server3810844174
arduino-language-server3814395713
arduino-language-server3983121514
arduino-language-server4008382493
arduino-language-server4036600816
arduino-language-server405221026
arduino-language-server4074092879
arduino-language-server4092249099
arduino-language-server4145582706
arduino-language-server416066127
arduino-language-server420888535
arduino-language-server4228930421
arduino-language-server4266281402
arduino-language-server4277413368
arduino-language-server4282199701
arduino-language-server4289948901
arduino-language-server433770066
arduino-language-server442701138
arduino-language-server472928638
arduino-language-server47576136
arduino-language-server503163025
arduino-language-server505798720
arduino-language-server508100230
arduino-language-server519039765
arduino-language-server555871190
arduino-language-server589946166
arduino-language-server649831026
arduino-language-server6845419
arduino-language-server684545036
arduino-language-server690556972
arduino-language-server693358139
arduino-language-server699494496
arduino-language-server841165341
arduino-language-server843406433
arduino-language-server844724269
arduino-language-server846847928
arduino-language-server854286938
arduino-language-server858022872
arduino-language-server87270584
arduino-language-server881169819
arduino-language-server913852425
arduino-language-server954170326
arduino-language-server967775854
arduino-language-server970171117
arduino-language-server979968397
arduino-sketch-02452AA76834037EB1984E1166B9365E
arduino-sketch-0DBF056A82589D4E68B454AAE9921DAF
arduino-sketch-486AC0BF5A54BA5BAB4EB0B11EB5F9E8
arduino-sketch-A29A7049194A10904AF761C3170B1F39
arduino-sketch-A2AC30869331FB2E1B2F119038A85F17
arduino-sketch-A39D91DC8D78B28E5212E8BE05DFE3D8
arduino-sketch-ABB516E60E972A8BC0DC9FDB13F8ACB2
arduino-sketch-E089A9C7017830D067EB8EB871EAA1A0

2

I've noticed the same.
The IDE leaves lots of turds behind.

There are also directories that don't have "arduino" in the name as well.

--- bill

1 Like
3

Thanks @Dougl. I have also noticed this. I submitted bug reports to the relevant issue trackers:

As for these:

their persistence is actually very beneficial because it means the cached compiled files can be reused even across separate sessions of Arduino IDE. Arduino IDE 1.x did clean these folders on exit and this is why you might notice the average duration of compilations and uploads is significantly less when using Arduino IDE 2.x compared to Arduino IDE 1.x.

Even if they are to be preserved, it might make sense to consolidate them under a dedicated folder as proposed here:

1 Like
4

IMO, Applications should ALWAYS clean up after themselves and not leave garbage files laying around after exiting.
It is ok if they create temp files for use during the session of the application but the application should remove all them when the application exits - particularly when those are in the /tmp area.

i.e. it is ok for the IDE and it's helper tools to create /tmp files so that subsequent builds after the first build (within the same IDE session) can be faster from doing some sort of caching, but once the IDE fully exits all these files should be gone/removed.

Yes it means that a first build after starting up the IDE may take longer but all subsequent builds within that same IDE session will be faster.
And when the final IDE window closes, all the files the IDE or any of its helper tools created should be gone/removed.

--- bill

1 Like
5

I agree but I might consider leaving things like cached/reusable build data in the IDE's work space as long as it has a preferences setting for aging it out and removal. Running the cleanup process after the IDE is up, boards and libraries validated and updated/etc would be preferred or even after the IDE has run its first compile.

I only found over 330MB of leftover stuff in my /tmp directory just now with 31MB of that being arduino-core-cache.

And even with all those droppings being left behind the current nightly-build does some form of processor intensive indexing on every IDE restart. Surely that too should have a "check on: startup, daily, weekly, monthly" option

6

330MB seems like a lot of garbage to me.
particularly since it is probably many directories and files.

IMO, turds are turds, and no matter how small, they are ugly and you just don't want any, even if they were to be piled up in just one area.

Now if the IDE & tools were to put some of the files (like pre-compiled library files) down under the platform area say down under ~/.arduino15/packages/ or ~/.arduinoIDE
in a specific area for the platform and individual core and board, that would make more sense if some of them were allowed to hang around after the IDE exits since that area is user specific and pre-built library files could be separated for each core within each platform and also for each board within that core.
Perhaps pre-building libraries for each board.
But the tools would have to make sure to be smart enough to handle all the necessary dependencies of header files and .cpp files and board files and then to have a way to clean things up should there be some kind of issue in the code.

Years ago I had proposed pre-building libraries into actual library archive files when they were installed or ever updated/modified. To make them actual libraries that are linked against instead of the current way of handling them as just .o files that are built when needed.

IMO, I simply would not go to the effort and just build whatever arduino "library" or indexing is needed on the first build and re-use it on subsequent builds and remove everything when the IDE finally exits.
This keeps things simpler which reduces the potential for issues/bugs.
While technically it may be more satisfying to do something fancy related to pre-building and caching to save files between IDE iterations, all it does is speed up that very first build of an IDE session but it increases the potential for bugs that could difficult to track down due to using incorrect pre-built or out of date objects/files etc...

All that said, IMO, the temporary files used for building sketches like pre-processed sketch files and any .o files for the user sketche should always be removed when the IDE exits.

I know it is way late to change this - and it was a big discussion years ago, and I lost, but, IMO, all the temp files needed to build a sketch should have been stored right where the sketch is.
It avoids lots of issues.
The issue back then was how to handle the bundled library example sketches since the IDE could be installed in a common area which could be read only to the user on a multi-user machine.

But now, aren't the platform files including examples all stored under the users home directory?
If so, the original issue that steered the IDE to do all this to use tmp the way does for sketches vs building in place no longer exists.
Maybe the use of building sketches in place could be revisited?

--- bill

1 Like
7

I should have put a wink icon next to that statement as it was more of a sarcastic plug at how much was really getting left behind. 330MB of 'turds' is a huge amount to be left around in my book.

I too like the idea of the sketch build system being located off of the sketch directory. I've done some commandline building of projects and it's a pain to keep looking for the latest build in /tmp and copying it to my own sketch/build directory.

I worry that the move to online building will result in choices being made to the locally installed IDE makes it a 2nd class citizen. Like maybe when run in the browser, these tmp files are cleaned up by the browser when the browser window is closed so they aren't being addressed for the local installed version.

8

I think this is the best approach. I have submitted a formal request to the relevant issue tracker:

It sounds good, but I suspect it might be more difficult to implement than you might think, considering the large number of potential target architectures. It is now possible for library authors to precompile for specific targets:

https://arduino.github.io/arduino-cli/latest/library-specification/#precompiled-binaries

The benefit of this should not be underestimated. If you are mostly working with AVR, it might not seem very significant, but the compilation time for some of the newer cores and libraries is very long. Even more so on a low spec PC, which is all some users have available.

Then you will be happy to learn about the -e flag of arduino-cli compile:

https://arduino.github.io/arduino-cli/latest/commands/arduino-cli_compile/#options

-e, --export-binaries              If set built binaries will be exported to the sketch folder.

As I already explained, they are preserved intentionally.

One of the most common praises of Arduino IDE 2.x you will see stated by users (even by those who otherwise criticize it) is the improved compilation time. That is the direct result of this changed behavior regarding the caches.

1 Like
9

speaking of commandline, I'm working on an esp32 project where I need to rebuild the esp32 core libraries to enable an external 32.768KHz crystal for the onboard RTC and I was wondering if there's a makefile or something in the temp structures which would allow me to move a library into the build via commandline? I thought I remembered there being a Makefile created in /tmp where the project can be built there manually but don't see that now.

10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.