Scheduler#

Scheduler is the central part of Lifeblood: it manages tasks and workers, viewers connect to it.

Refer to Overview of Lifeblood to understand the main concepts.

Warning

Since Scheduler manages all the resources, there should only be one single scheduler running on your network.

First of all, you need to make sure that every component is configured to reach scheduler. This may be done by manual configuration, or by relying on automatic broadcasting.

Broadcasting#

By default Scheduler will start broadcasting it’s address over the local network (every 10s by default), and by default every component will start listening to scheduler’s broadcasts.
This way other components (worker, viewer) will be able to automatically connect to it when started from anywhere within the LAN.
You should never start 2 or more broadcasting schedulers in the same LAN, otherwise their broadcasts will collide and workers and viewers will get confused.

You can disable broadcasting in scheduler’s config file, but then you will have to properly configure workers and viewers manually so they know where to connect.

Note

usually networks are configured so that broadcast is not propagated through bridges and gateways, so if you have some complicated network topology - you need to configure components manually. Defaults work best for small home/company networks.

But if you do want to change the defaults and disable broadcasting, default scheduler config comes with commented preset for this.

  • To disable the broadcasting, just uncomment this line broadcast = false

  • To specify ip address to use server_ip = "192.168.0.234" (with your address obviously)

  • You can specify a separate ip to be used for UI with ui_ip = "172.1.2.3", otherwise server_ip will be used

refer to scheduler_configs for details

Database#

Probably the most important part of the configuration is where your scheduler’s database is stored.

A scheduler’s database is something like a farm manager repository - it’s where all nodes and tasks are stored.

Lifeblood uses sqlite as it’s database engine.

By default, the database file location is set to be next to scheduler’s config file in Config location

However it may be overriden by config entry scheduler.database.path, or command line argument --db-path.
It is quite reasonable to have multiple databases to test different things around.
However the main idea of Lifeblood is to set up your pipeline logic in one single database.

Note

it is better to create the database on an SSD drive if possible, as it will be much faster, especially on huge databases. Though database on HDD is quite fine for low task load, but the lag may be noticeable.

Warning

do NOT run multiple schedulers with different databases at the same time. Though it is supported in general - it requires some configuration, like disabling broadcasting. So you need to know what you are doing

Logging#

All Lifeblood components log to stdout, as well as to a log file.
Log files location is:

  • /home/<username>/.local/share/lifeblood/log (or $XDG_DATA_HOME if defined) (linux)

  • C:\Users\<username>\AppData\Local\lifeblood\log (based on %LOCALAPPDATA%) (windows)

  • /Users/<username>/Library/Application Support/lifeblood/log (mac)

By default all components of Lifeblood are set to log only “important” messages (like warnings and errors), but to figure out what’s happening sometimes you would need a bit more information.

All of Lifeblood’s components can accept --loglevel parameter before command to specify minimum log level to, well, log.
for example lifeblood scheduler --loglevel DEBUG will set default log level to DEBUG and you will see all the crap printed out into stdout
On this page
Show Source