The Scheduler service

The Scheduler is the new maintenance system developed specifically for etke.cc subscribers to give control over server maintenance and help solve common issues like disk utilization and service restarts.

Moreover, you may choose between different stability branches for your homeserver.

How to start

Start a chat with @scheduler:etke.cc and send help to get instructions

NOTE: that bot works only for etke.cc customers, so it won’t work for other users.

Modes

Scheduler supports 4 work modes, you may use all of them at the same time. Rule of thumb - you should have at least recurring maintenance to be sure that your server is updated and protected.

Run

The run mode will immediately run a command , for example:

  • @customer: run ping
  • @scheduler: Command execution has been started. Please, keep in mind that it may take some time. You will receive a message when it’s done.
  • @scheduler: command execution of run ping succeeded
INFO [etke.cc] disk usage: 48%

See the full list of available commands here .

Schedule

The schedule mode will schedule a command execution for a specific date and time (UTC), for example, if you want to perform maintenance of your server on July 1st at 5pm UTC:

  • @customer: schedule maintenance 2022-07-01 17:00
  • @scheduler: Command execution has been scheduled.

and on the July 1st at ~5:30pm UTC (maintenance takes some time) you will receive the following message:

Yes, there is no mistake - the schedule mode just schedules the run mode for a specific date and time in the future

Recurring

The recurring mode sets the recurring schedule mode to a specific weekday and time. By default, you will have the maintenance command set to a random weekday and time (etke.cc maintenance service), so instead of manual runs or schedules every time you want to schedule some command that mode will automatically create corresponding schedule to run the command you choose on specific weekday and time. For example, you want to get server maintenance every Friday at 3pm UTC:

  • @customer: recurring maintenance Friday 15:00
  • @scheduler: Recurring schedule has been set.

and every Friday at ~3:30pm UTC (maintenance takes some time) you will receive the following message:

  • @scheduler: command execution of run maintenance succeeded

NOTE: you may set only 1 recurring schedule per command (eg you can have only 1 recurring maintenance), so multiple recurring configurations of the same command (e.g. recurring maintenance Friday 15:00 and recurring maintenance Monday 17:00) will replace each other and you will end up with only one recurring maintenance configuration (the last one) – on Monday 17:00 UTC

List

List mode just lists your runs (executed commands and result of execution), schedules, and recurring schedules, useful in case you want to check something.

Examples:

  • @customer: list runs
  • @scheduler:
* 2022-06-12 16:36: run ping
* 2022-05-30 22:01: run maintenance
* 2022-06-19 16:03: run restart slack failed: exit status 1
  • @customer: list schedules
  • @scheduler:
* 2022-06-27 16:00: run ping (recurring)
* 2022-07-01 17:00: run ping

NOTE: the (recurring) suffix above indicates that the given task was automatically scheduled, because there’s a (weekly) recurring schedule for it. Only the first (nearest) future recurrence date is indicated.

  • @customer: list recurring
  • @scheduler:
* Monday 16:00: run ping

Alert

Apart from server management features, Scheduler will automatically alert you when something is wrong with your server, for example about high disk usage or unreachable API endpoints (of your matrix server).

Example of a high disk utilization alert:

🟥 etke.cc: Disk Utilization > 80%

Please, note that Scheduler will automatically start a chat with you if you don’t have one already.

Commands

ping

That command will check server reachability and disk utilization, useful when you’re applying a new firewall or just want to be sure that you have free space to upload 5GB of cat photos.

Example:

  • @customer: run ping
  • @scheduler: Command execution has been started. Please, keep in mind that it may take some time. You will receive a message when it’s done.
  • @scheduler: command execution of run ping succeeded
INFO [etke.cc] disk usage: 48%

disk

That command will check common server components’ disk utilization and send it as a chat message. This is useful when you need to understand why disk utilization is so high.

Example:

  • @customer: run disk
  • @scheduler: Command execution has been started. Please, keep in mind that it may take some time. You will receive a message when it’s done.
  • @scheduler: command execution of run disk succeeded
INFO [etke.cc] disk usage: 65%
INFO [etke.cc] Database: 5.9G
INFO [etke.cc] Database backups: 8.6G
INFO [etke.cc] Media: 3.8G

maintenance

That command triggers the maintenance process, which takes 15-30 minutes to complete. You can learn more on the services page

Example:

  • @customer: run maintenance
  • @scheduler: Command execution has been started. Please, keep in mind that it may take some time. You will receive a message when it’s done.
  • @scheduler: command execution of run maintenance succeeded

restart

That command restarts a systemd service, useful when you see that a bridge is hung and not responding. It has an internal mapping between “human-friendly” service names and actual service names, so if you want to restart the facebook bridge, you can use run restart facebook instead of run restart matrix-mautrix-facebook (though, the latter will work, too)

Example:

  • @customer: run restart slack
  • @scheduler: Command execution has been started. Please, keep in mind that it may take some time. You will receive a message when it’s done.
  • @scheduler: command execution of run restart slack succeeded

NOTE: for the schedule and recurring modes, the restart command requires the service name to be after the date/weekday and time, for example: schedule restart 2022-07-01 17:00 slack or recurring restart Monday 17:00 slack

Stability branches

The Scheduler was developed with the assumption that some customers may prefer stable, but slower updates, and others may prefer unstable, but much faster updates to get the freshest possible versions as soon as possible.

You may choose the stability branch that will suit your needs. If you want to switch the stability branch of your homeserver, just let us know by sending us a message .

stable (default)

stable, as the name suggests is our more-stable (more tested) stability branch, compared to fresh . It’s typically a few days (up to a week) behind our fresh branch.

With the default stability branch, we collect updates of the components during the week and first test them on developers’ servers, on open-source community members’ servers, and on customer servers which are explicitly opted into using the fresh stability branch. It’s only after all this testing that do we publish these updates in the stable branch, so you can install them during maintenance and be sure they won’t break anything.

stable is the default stability branch that we use on all customer servers, except for customers who have explicitly asked us to use fresh.

fresh (testing)

This branch receives updates as soon as possible, so you get the freshest updates used by developers and the open-source community. Such updates may sometimes contain breaking changes, but we usually prepare workarounds and migrations before publishing them. Use this (fresh) stability branch if you’d like to get updates as soon as possible (up to 1 week earlier than stable), at the expense of a higher potential for breakage.

We have a special room #fresh:etke.cc where updates are published almost in real-time.