Version 0.8.34

• Fixed typo in installer script.

Version 0.8.33

• Attempting to preserve add-on modules during update: couchbase, aws-sdk and redis
• npm update seems to clobber these on Cronicle upgrade (sigh)

Version 0.8.32

This version contains a fix from user @BitProcessor. If you are running Cronicle with a single master server but also behind a load balancer, you can add a new client.custom_live_log_socket_url configuration property to have the web browser use that URL instead of the direct server IP or hostname.

Commit: 55c6489

Version 0.8.31

• Fixes #195 - TypeError: Cannot read property 'toString' of null - thanks to @raymatos

Version 0.8.30

• Fixed bug where error chain reactions were executed even if job was manually aborted.
  • Thanks to user @Jacketbg for finding this bug, mentioned in issue #190

Version 0.8.29

This is a minor release with a few small fixes.

• Fixes #182
• Addresses security issue where hashed user password and salt were getting logged.
• Fixed date handling in Time Machine text field when custom timezones are involved

Version 0.8.28

One small bug fix in this release:

Issue #112

I think it should be noted here that Cronicle has some limits, which this bug exercised quite nicely. The main schedule, for example, is only designed to handle a few hundred items, possibly a thousand at the extreme maximum. The author of issue #112 was trying to push this far beyond that soft limit, and thus it inevitably caused memory issues. The Cronicle schedule is stored in memory at all times, and synced to all clients, so it needs to be small and compact.

The schedule is really intended as a replacement for a Crontab. That is, with a relatively small amount of repeating events, possibly hourly, daily, or weekly. It isn't meant to hold a large number of arbitrary events.

Perhaps I will look into redesigning this in v2.0.

Version 0.8.27

This release addresses a timer integer overflow bug in Node.js core, by emitting a warning message on startup if you are running on an affected version. The bug affects Node.js v10.0.0 to v10.8.0, and is fixed in Node v10.9.0.

For more information see Issue #108, which is now marked as fixed.

Version 0.8.26

One single change in this release:

Reversed course on new /api/app/status API call. It no longer causes a server restart on a tick age issue (i.e. broken timer). It now only logs a level 1 debug message, and safely returns an API response. Server restarts should only be handled by an external monitoring tool.

This tick age thing is an ongoing investigation into a very strange situation, seen after about 20 days of continuous running on Linux CentOS 7.2, Node v10.6.0 and AWS (S3) storage backend. Seemingly at random (but on multiple servers at the same time), all the Node.js timers and intervals seem to cease firing, but all other actions triggered by sockets or child processes keep running. The Cronicle daemon has to be restarted, sometimes SIGKILLed. CPU and memory are both fine.

I'm currently dumbfounded as to what could cause such a thing.

Version 0.8.25

A few small changes in this release:

• Removed old garbage collection hack (was from the old Node v0.12 days).
• Added new /api/app/status API call for monitoring purposes.
• Disable UDP broadcast server if port is zero or false.
• Now keeping track of tick age (exposed in api_status).
  • If tick age is over 60 and status API is invoked, server will self-restart (should never happen).
  • A tick should fire every second, so if 60 seconds has passed, something is very wrong.
• Improved logging for crashes and emergency shutdowns.
• Added PID log column by default.
• Bumped pixl-server version to v1.0.15.