Rospy and os.mkdir() issue - unable to create a directory [closed]
Hi guys!
I have posted on Stackoverflow this question however since it's also ROS-related I've decided to do that here too. My original post is located here.
I have created a dashboard (inheriting from the Dashboard
class based on rqt
). I have followed the source code from PR2 and COB in order to populate my widget. In addition some of my toolbar entries also open views containing one or multiple widget (subclassing QWidget
) of the same type. Each widget is bound to a ROS process that is taken from a configuration loaded on the parameter server. The purpose of the widget is to allow basic control (start,stop) as well as monitoring of the ROS process status (inactive, running, finished, failed). In the image below you can see more or less how things are connected internally:
There are several goals that the launched bash script (in the image noted as Bash (detached)
) has to fulfill are as follows:
- Remain alive even when my UI crashes/is closed - in my main scenario all the processes started by my dashboard have to continue running even when the dashboard itself stops working (for whatever reason)
- Launch a ROS node/nodes (using
rosrun
,roslaunch
orrosservice call
(with aTrigger
-type feedback)) as a background process - Write the ROS process's PID in a file
.proc
- this PID is then used by my widget to control and monitor the process (usingkill
). - Retrieve the exit code of the spawned ROS process - the exit code is again written to
.proc
and can be read by my widget
This solution allows me to continuously monitor a ROS process even if my dashboard stops working (breaks down or is stopped intentionally). Both the .bash
and .proc
files are further used to restore the state of the application upon relaunch. More on this design can be seen here.
Now I'm currently facing a strange problem (as described in the first link in this post) - whenever I call os.mkdir()
following doesn't happen:
- no directory is created (even though it doesn't exists) - the path of the directory is correct. I have used my interactive Python interpreter to do that same procedure of creating it and it worked
- no exception is raised - my
rospy.logerr()
orrospy.loginfo()
seem to be unable to display any exception (if such is raised in this case at all).
Here is the code that I use to create the directory:
def checkRootDirExists(self):
'''
Check if the process folder is present and create it if not
'''
if not exists(self.dir_name): # Using os.path.exists()
rospy.loginfo('SR2: Process directory "%s" doesn\'t exist and therefore will be created', (self.dir_name+'/'))
try:
mkdir(self.dir_name)
except OSError as e:
if e.errno != errno.EEXIST:
rospy.logerr('Directory exists')
elif e.errno != errno.EACCES:
rospy.logerr('Access violation')
else:
rospy.logerr('Something else happened')
else:
rospy.loginfo('SR2: Process directory "%s" already exists', (self.dir_name+'/'))
I have tried simply using except ...
The only case that you don't have a log statement for is success. Why not add a log statement immediately after
mkdir
to confirm that it's succeeding?No need for that. A success would be a created directory. Since no directory is created it is obviously failing. :P That said I added a
loginfo()
entry right after callingmkdir()
and I got its output on my screen. This would mean no exception has been raised, right?I just want to exclude ROS as the reason for this strange behaviour.
It looks like os.mkdir is succeeding. If you're running your node through roslaunch, it will change the working directory. Are you sure you're passing an absolute path to os.mkdir() ?
I am getting close to the source of the problem.
os.mkdir()
is succeeding but for some reason it does that to a much later point. I do believe that the problem is the whole multiprocess/multithreading model I have. It may be due to delays in the processing of the events that I have.Sadly due to the fact that I am starting detached processes the ouptut (errors etc.) for the ROS processes that I am launching comes at a much later point in time - after they get killed. This is...terrible. LOL I have no idea how to fix all that.