I have been having issues snapping my ROS project for the last couple days where when I build my snap with no daemon and run it manually it is fine (for longer then the 2 hours I tested it), however when I build it with a simple daemon it freezes the entire system almost as soon as it installs and then whenever it starts. I managed to boot long enough to uninstall it once however generally I don’'t have time.
I have not made any changes to the core code that I am running and have tried removing practically all of my ROS packages but yet this behaviour remains.
I will keep trying new things an will update this post if I get any more information.
When you say “run it manually,” what do you mean? What confinement type are you using? Any chance you’re able to simplify this into an example that we can try ourselves in order to help?
By manually I mean sudo snap run ..... That seemed to work every time just fine but once I snapped it with a simple daemon it would freeze.
I am just going to try building on a different computer to make sure its not just my laptop. If it still doesn’t work I will try it with one of the simple ROS example and post the results.
I am in the same boat. I can run my ROS snap when built without the daemon, but when I set daemon: simple the service fails every time. I believe it has to do with setting the source, as in source ~/catkin_ws/devel/setup.bash. That is the command you normally run when running ROS, and when I am required to run source /snap/ROSsnap/current/opt/ros/kinetic/setup.bash before my snap will run manually. I am concerned that the snap is not referencing the correct setup.bash when it tries to run as a service.
I am not sure if we have the same problem, but they seem similar. I am using classic confinement as I couldn’t get it to run in devmode.
For me it seems to be related to the environment as well, I will try setting the source first to see if that works.
I have since tested a set snap on five computers, three of which it fails within a minute of boot and are all the same hardware and environment, while on the other two (a VM and a fresh install on a bench PC) it runs fine and has no issues forover a week.
Am I correct in assuming the the sourcing of my testing workspace from my .bashrc file will not be run unless I open a terminal, hence not effecting the snap?
For the last two months I have been unable to recreate this issue and it is now present again on a computer which has been running fine for the last 2 or so weeks. There have been no changes to my snap at all.
Is it possible that there is something that my snap will call when it starts? Is it possible that it could be to do with the core snap which is required to be installed?
Can you please share the meta/snap.yaml file (in private or censored if you wish). I’m mostly interested in the applications, interfaces, layouts and other “execution” aspects of your program.
snap changes does not produce anything relevant since to get into the PC I disabled all the startup calls which broke the core snap and the only way I could get it working again was by reinstalling.
snap.name.run.service - Service for snap application name.run
Loaded: loaded (/etc/systemd/system/snap.name.run.service; disabled; vendor preset: enabled)
Active: inactive (dead)
It was disabled using a live boot of Ubuntu so that we could access the PC normally.
I will reinstall the snap at a later date, I don’t want to do it now and risk freezing the PC.
Weirdly it can now be run again without freezing anything. I don’t really know what changed again. (removed some files and that is about it). As mentioned above I will reinstall it later and see if it works.
