cronitorio / cronitor-cli Goto Github PK

View Code? Open in Web Editor NEW

78.0 6.0 14.0 26.17 MB

Command line tools for Cronitor.io

Home Page: https://cronitor.io/docs/using-cronitor-cli

License: MIT License

Shell 15.38% Go 84.62%

cronitor cron crontab

cronitor-cli's People

Contributors

Stargazers

Watchers

Forkers

tmarinatucker progmem jdotjdot ahmedhmn meoww-bot developgo shaneharter wisner23 jorgeluizetibr mission2566 asphaltbuffet

cronitor-cli's Issues

Cronitor runs commands in bash and refuses to use zsh

My system runs cron commands in zsh, and SHELL is appropriately set in my crontab config.

However, cronitor insists on using bash for executing commands with cronitor select.

Can I change this behaviour? It defeats the purpose of using Cronitor at all if it cannot replicate the environment that Cron will run under

fix deprecated use of rand.Seed

cronitor-cli/lib/utils.go

Line 9 in 352419e

rand.Seed(time.Now().Unix())

Deprecated use of rand.Seed that should be minimally refactored to isolate it from other package calls.

Reference: https://pkg.go.dev/math/rand#Seed

Non-interative `cronitor discover`?

Is there a way to run cronitor discover interactively and tell it to look only at my user-specific crontab? I'm trying to automate cronitor setup with ansible.

disable and purge sistem

Hello, I need to uninstall the debian/gnu cronotor

cronitor-cli no longer working in Alpine Linux

I build cronitor-cli into one of my docker images which uses alpine linux 3.13 and recently noticed the download URL changed, so I updated that, but then realized cronitor-cli no longer worked.

Commands I run in Dockerfile

 RUN curl -sOL https://cronitor.io/dl/linux_amd64.tar.gz                                                                                     
 RUN tar xvf linux_amd64.tar.gz -C /usr/bin/

Output from command

/web # /usr/bin/cronitor 
/bin/sh: /usr/bin/cronitor: not found
/web # ls -l /usr/bin/cronitor
-rwxr-xr-x    1 root     root      14678502 Oct  4 14:38 /usr/bin/cronitor

I realized the previous version I had been downloading from https://cronitor.io/dl/cronitor-stable-linux-amd64.tgz had been statically linked, and the new version in 28.2 is dynamically linked. I confirmed this by fetching the tar.gz Source Code and compiling it statically, which then worked inside alpine linux. I used this command,

go build -ldflags '-linkmode external -w -extldflags "-static"'

Is this something where you may go back to a statically linked binary or do you have a different recommendation?

Issue installing CronitorCLI in MacBook Air M1

Hello,

The steps listed in the documentation to get the CronitorCLI up and running are as follows:

curl -sOL https://cronitor.io/dl/cronitor-stable-darwin-amd64.zip
sudo unzip cronitor-stable-darwin-amd64.zip -d /usr/bin/

The first command successfully creates the zip file. However, the second command has an access error.

Cronitor discover fatal error.

Ubuntu 21.04 (GNU/Linux 5.11.0-37-generic x86_64)
CronitorCLI version 28.4

I installed Cronitor using the following curl https://cronitor.io/install-linux?sudo=1 -H "API-KEY: ABC123" | sh and when I run cronitor discover I get the following error.

Any help would be awesome. Thanks!

[signal SIGSEGV: segmentation violation code=0x1 addr=0xe5 pc=0x7f3e1794dc74]

runtime stack:
runtime.throw({0x8f412f, 0x0})
	/usr/local/go/src/runtime/panic.go:1198 +0x71
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:719 +0x396

goroutine 1 [syscall]:
runtime.cgocall(0x7909b0, 0xc0000f5878)
	/usr/local/go/src/runtime/cgocall.go:156 +0x5c fp=0xc0000f5850 sp=0xc0000f5818 pc=0x4040bc
os/user._Cfunc_mygetpwuid_r(0x3e8, 0xc000268390, 0x2694d80, 0x400, 0xc000010148)
	_cgo_gotypes.go:172 +0x4c fp=0xc0000f5878 sp=0xc0000f5850 pc=0x7570ec
os/user.lookupUnixUid.func1.1(0x3e8, 0xe90680, 0xc0000f5910, 0x40dce7)
	/usr/local/go/src/os/user/cgo_lookup_unix.go:105 +0xa6 fp=0xc0000f58d8 sp=0xc0000f5878 pc=0x757826
os/user.lookupUnixUid.func1()
	/usr/local/go/src/os/user/cgo_lookup_unix.go:105 +0x29 fp=0xc0000f5908 sp=0xc0000f58d8 pc=0x757769
os/user.retryWithBuffer(0xc000237d10, 0xc0000f59e8)
	/usr/local/go/src/os/user/cgo_lookup_unix.go:249 +0x39 fp=0xc0000f5950 sp=0xc0000f5908 pc=0x757e59
os/user.lookupUnixUid(0x3e8)
	/usr/local/go/src/os/user/cgo_lookup_unix.go:98 +0x118 fp=0xc0000f5a28 sp=0xc0000f5950 pc=0x757578
os/user.current()
	/usr/local/go/src/os/user/cgo_lookup_unix.go:51 +0x47 fp=0xc0000f5a68 sp=0xc0000f5a28 pc=0x757447
os/user.Current.func1()
	/usr/local/go/src/os/user/lookup.go:15 +0x17 fp=0xc0000f5a78 sp=0xc0000f5a68 pc=0x757f37
sync.(*Once).doSlow(0xc0000f5b60, 0x40d994)
	/usr/local/go/src/sync/once.go:68 +0xd2 fp=0xc0000f5ae0 sp=0xc0000f5a78 pc=0x46c9d2
sync.(*Once).Do(...)
	/usr/local/go/src/sync/once.go:59
os/user.Current()
	/usr/local/go/src/os/user/lookup.go:15 +0x37 fp=0xc0000f5b10 sp=0xc0000f5ae0 pc=0x756ef7
github.com/cronitorio/cronitor-cli/cmd.glob..func5(0xe369a0, {0xec68f0, 0x0, 0x0})
	/github/workspace/cmd/discover.go:134 +0x3e fp=0xc0000f5d00 sp=0xc0000f5b10 pc=0x78d5be
github.com/spf13/cobra.(*Command).execute(0xe369a0, {0xec68f0, 0x0, 0x0})
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:844 +0x5f8 fp=0xc0000f5dc0 sp=0xc0000f5d00 pc=0x58def8
github.com/spf13/cobra.(*Command).ExecuteC(0xe361c0)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:945 +0x38d fp=0xc0000f5e78 sp=0xc0000f5dc0 pc=0x58e54d
github.com/spf13/cobra.(*Command).Execute(...)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:885
github.com/cronitorio/cronitor-cli/cmd.Execute()
	/github/workspace/cmd/root.go:53 +0x25 fp=0xc0000f5ea0 sp=0xc0000f5e78 pc=0x7895c5
github.com/getsentry/raven-go.(*Client).CapturePanicAndWait(0x200000003, 0xc0000001a0, 0xc0000f5f70, {0x0, 0x404111, 0x790db0})
	/go/pkg/mod/github.com/getsentry/[email protected]/client.go:822 +0xac fp=0xc0000f5f20 sp=0xc0000f5ea0 pc=0x75342c
github.com/getsentry/raven-go.CapturePanicAndWait(...)
	/go/pkg/mod/github.com/getsentry/[email protected]/client.go:828
main.main()
	/github/workspace/main.go:41 +0x1c5 fp=0xc0000f5f80 sp=0xc0000f5f20 pc=0x790805
runtime.main()
	/usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc0000f5fe0 sp=0xc0000f5f80 pc=0x436767
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc0000f5fe8 sp=0xc0000f5fe0 pc=0x4641e1```

when entering the api key

sudo cronitor configure --api-key xxxxx

/usr/bin/cronitor: 1: /usr/bin/cronitor: Syntax error: end of file unexpected (expecting ")")

are there pinned version cronitor download links?

hi! curious if there is an alternate to the #installation download link (https://cronitor.io/dl/cronitor-stable-linux-amd64.tgz) where we can download a pinned version of the cronitor cli, eg .../dl/cronitor-25.0-linux...

Cannot open tar

(base) jeremycherfas@192 ~ % sudo tar xvf darwin_amd64.tar.gz -C /usr/bin/
x cronitor: Can't create 'cronitor'

That's it. No further explanation available.

Can you please suggest how to fix this?

Cronitor for ARM?

I see that the packages available for Cronitor only exist for amd64 (x86_64), on Windows, macOS and Linux. Is there any way to use Cronitor on ARM? I apply the question for Windows (ARM), macOS (Apple Silicon) and Linux (ARM), in general I would benefit Croniton on such a popular device for programming tasks as the Raspberry PI.

'Syntax error: "|" unexpected' when configuring API key

I was following the setup instructions, and everything seemed to work fine until I tried executing the third statement to configure the API key. As the title indicates, I got the error /usr/bin/cronitor: 1: Syntax error: "|" unexpected.

I'm running Raspbian GNU/Linux 11 (bullseye) on a Raspberry Pi 4.

crontab.Save does not update crontab field

cronitor-cli/lib/crontab.go

Line 159 in 4f58a8b

c.IsSaved = true

Crontab is not passed in as a pointer so the assignment on line 159 is ineffective.

Interactive Addition - Skipped Lines (Ctrl-C) and Overescaping

In a server I have Cronitor installed on, I have the following @reboot line, which I'm skipping any time we need to add tasks with cronitor discover, since we already have other monitoring solutions in place (and I didn't think Cronitor supported @reboot):

@reboot /bin/bash -l -c 'cd /path/to/application && ./reboot_task.sh'

This is deemed a "complex" line by CronitorCLI, and given the following flow...

Run cronitor discover
Skip the @reboot line
Add, update, or otherwise hit Enter/Return on any other line
Cronitor updates the crontab and submits changes

...I end up with the following below over multiple runs:

@reboot "/bin/bash -l -c 'cd /path/to/application && ./reboot_task.sh'"
@reboot "\"/bin/bash -l -c 'cd /path/to/application && ./reboot_task.sh'\""
@reboot "\"\\"/bin/bash -l -c 'cd /path/to/application && ./reboot_task.sh'\\"\""

Due to escaped characters getting re-escaped over multiple runs, I ultimately end up with tasks outside of Cronitor's monitoring that no longer perform what they need to.

As a note, I am not a Go developer by trade, but I did try hacking on it a little bit, and came up with a possible solution that appears to work when I build and run, by only modifying lines that are receiving a monitor code for the first time.

Add built-in support for timeout

It would be great to add built-in support for the options from timeout. Specifically, it would be great to be able to do something like:

cronitor --timeout-secs 600 --kill-after-secs 30 --signal HUP some/command/here

Here is the full help output for timeout on my osx system:

% timeout --help
Usage: timeout [OPTION] DURATION COMMAND [ARG]...
  or:  timeout [OPTION]
Start COMMAND, and kill it if still running after DURATION.

Mandatory arguments to long options are mandatory for short options too.
      --preserve-status
                 exit with the same status as COMMAND, even when the
                   command times out
      --foreground
                 when not running timeout directly from a shell prompt,
                   allow COMMAND to read from the TTY and get TTY signals;
                   in this mode, children of COMMAND will not be timed out
  -k, --kill-after=DURATION
                 also send a KILL signal if COMMAND is still running
                   this long after the initial signal was sent
  -s, --signal=SIGNAL
                 specify the signal to be sent on timeout;
                   SIGNAL may be a name like 'HUP' or a number;
                   see 'kill -l' for a list of signals
  -v, --verbose  diagnose to stderr any signal sent upon timeout
      --help     display this help and exit
      --version  output version information and exit

DURATION is a floating point number with an optional suffix:
's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days.
A duration of 0 disables the associated timeout.

Upon timeout, send the TERM signal to COMMAND, if no other SIGNAL specified.
The TERM signal kills any process that does not block or catch that signal.
It may be necessary to use the KILL signal, since this signal can't be caught.

EXIT status:
  124  if COMMAND times out, and --preserve-status is not specified
  125  if the timeout command itself fails
  126  if COMMAND is found but cannot be invoked
  127  if COMMAND cannot be found
  137  if COMMAND (or timeout itself) is sent the KILL (9) signal (128+9)
  -    the exit status of COMMAND otherwise

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/timeout>
or available locally via: info '(coreutils) timeout invocation'

My use case is cron tasks that sometimes stall (maybe a bad database connection or similar) and should be marked as failed. We run the cronitor cli in environments with only bash built-ins, so the timeout binary wouldn't be available there.

Additional output formats for "list"

I think it would be fantastic to provide additional output formats. Initially a JSON representation of all cron jobs would be very useful. I don't have the time to work up a PR myself, but perhaps someone else could take it on?