Can I run OSMC and an unrelated script in parallel?

As the subject says I want to run a python script that communicates between my alarm system and a home automation hub on my new pi 2 always & forever. I’d like to be able to start/stop kodi/OSMC as needed as well without interrupting the other process. Is this possible with OSMC or do I need raspbian instead? There are a few threads on this but I can’t tell if the other script is media center related. Mine isn’t, at all.

Why stop kodi?

I thought the pi might produce excessive heat with it running 24x7.

Unlikely. Also, pi will shut itself down at 85°celcius to prevent overheat. It’s designed to run continuously.

Your request sounds overly complicated.
OSMC is an OS. Running a script without an OS does not make sense. So you probably mean you want to run a script besides Kodi, which is the biggest process running on the OS.

This is extremely simple:

Option 1: scheduler to run your script
go to My OSMC > Services, enable cron.
Google how Cron works and use it to schedule when your script should run.

Option 2: a service that runs a program
you could add a .service file and enable it with systemctl enable my.service, then start it with systemctl start my.service. This is how you can start/stop any process on OSMC including Kodi. An easy how-to can be found in the How-To Install Syncthing topic in the How-To section of the forum.

1 Like

@zilexa Thanks! Yes I did indeed think that OSMC might be an inseparable meld of xmbc/kodi and linux, perhaps without access to the OS. I think OpenELEC is like this. I will read the how-to on starting a service.

The “autostart at boot” part is what you need. But I am no expert on .service files, can’t help you with that. I also did not create that file for Syncthing, it’s from Syncthing’s own documentation. Basically any guide or documentation on how to create your own service to run on a Linux based system should help you, as long as it’s about systemctl since that’s what Debian uses, which is what OSMC is based on.

FTFY :wink:

Thanks for correcting me! I also need to do some more reading on that :smile:

OSMC can do lots and lots and lots of things besides run Kodi. Raspberry Pi + OSMC = :heart:

Well thanks to @zilexa I got the service running fine but -big but- the script it calls won’t talk to my ST hub unless I’m logged in as root. Do I need something else in the service script to allow communication?

#AlarmServer systemd service file for OSMC
#Path should be /lib/systemd/system/alarmserver.service


ExecStart=/usr/bin/python /usr/AlarmServer/


Could put it in root’s crontab.

sudo crontab -e

Perhaps user osmc has no right to run this script? Strange. It should work like any other service.

If your script must run as root then just remove the User and Group lines in your service - services run as root by default unless you specify otherwise.

Found it! I noticed that although the service would run as a standard user, the zone names were generic and the logfile wasn’t getting written to. That along with not communicating to the smartthings hub led me to believe my .cfg file wasn’t getting read. It contains OAuth tokens.

I found this in

if name==“main”:
print(‘Using configuration file %s’ % conffile)
config = AlarmServerConfig(conffile)

and changed it to:

if name==“main”:
print(‘Using configuration file %s’ % conffile)
config = AlarmServerConfig(conffile)

Now all is well, the service starts and runs behind kodi. Pretty sloppy hard-coding the path like that though, if a hardware guy like myself can go so far to say. I also don’t understand why running as root worked. Can anyone explain that part to me?

When you run a script as a service it does not have the same PATH or environment that you would get in an interactive login shell, so just because a script works from the command line doesn’t mean it will work without modification as a service, especially if it makes assumptions about what the current directory is, what the PATH includes and so on.

Without seeing the full script it’s hard to be sure but it does look like the script is written with the assumption of the cfg file being in the current working directory when run - with a system service you can’t make such assumptions.