etke.cc
the only FOSS-based service offering Matrix chat server hosting
  etke.cc
  - the only FOSS-based service offering Matrix chat server hosting
🌓 Theme

The Scheduler service

🌐 This page is also available in: Deutsch
Non-English support is best-effort. The English version is more complete.

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:

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:

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:

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

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:

* 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

* 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.

* 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:

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:

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:

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:

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.