Opened 10 years ago

Closed 13 months ago

Last modified 13 months ago

#613 closed defect (fixed)

clean_temp: not safe for concurrent use

Reported by: hamish Owned by: grass-dev@…
Priority: normal Milestone: 7.6.0
Component: Startup Version: 6.4.0 RCs
Keywords: clean_temp init grass.py Cc:
CPU: All Platform: All

Description

if you do $ grass65 -gui you will see that it prints "Cleaning up temporary files ..." from init.sh line # 415 devbr6). i.e. before the interactive startup.

But the new LOCATION_NAME and MAPSET are not really finalized until after about line 711.

So it's a bummer if you startup another session of GRASS while you have some process running in the first (good chance the first is the mapset stored in .grassrc6) which is using temp files. Init.bat has similar issues, and I would guess that windows isn't as forgiving when you attempt to delete open files.

if it's a shell script running there's no guarantee that the file will be kept open between when it's written and when it's needed. could be a real pain for long running process to have .tmp disappear mid calculation.

Hamish

Change History (6)

comment:1 Changed 6 years ago by hamish

Component: DefaultStartup
Milestone: 6.4.06.4.4

comment:2 Changed 3 years ago by neteler

Milestone: 6.4.46.4.6

comment:3 Changed 14 months ago by wenzeslaus

Keywords: init grass.py added
Milestone: 6.4.67.6.0

This still might be an issue. clean_temp() (which calls clean_temp) is called on line 2040 while mapset is set and ready later on line 2087. Same in 7.0 and trunk (7.7). (Now I have second thoughts about closing #1286, but if it is an issue (location being set, but possibly garbage), it is really this one anyway.)

comment:4 Changed 14 months ago by wenzeslaus

My current understanding is that that clean_temp is called in grass.py right when it checks if it determines that it is not a new user which is taken as a reason to clean the current mapset. Unfortunately the current mapset is the last used mapset, not necessarily the one requested. The mapset locking happens later on and only after that we can clean the mapset. Therefore, I will move the clean_temp call only after the lock.

Note: There is another clean_temp at the end. My assumption is that the start time one is meant to clean the mapset just in case.

comment:5 Changed 13 months ago by wenzeslaus

Resolution: fixed
Status: newclosed

In 73342:

init: clean mapset only after locking it (fixes #613, see #1286)

Only after we set the user-requested mapset as current (GISRC) and lock it,
we can do the startup cleaning using clean_temp (to clean after previous sessions
if needed).

The cleaning was in place at least since r11260 but it got moved to a wrong place some
time after that but before r37863.

comment:6 in reply to:  4 Changed 13 months ago by hamish

Replying to wenzeslaus:

Note: There is another clean_temp at the end. My assumption is that the start time one is meant to clean the mapset just in case.

Yes exactly right, as the previous session may have ended uncleanly with a crash/kill/reboot.

best, Hamish

Note: See TracTickets for help on using tickets.