Salt: cron.rm_job and cron.rm_special do nothing (state cron.absent also broken)

[James00001]

Description of Issue

The cron module's features for removing cron jobs appears to be broken in salt 2019.2.1
Neither cron.rm_job nor cron.rm_special seems to do anything at all. They don't report any failure, but the don't remove the matching job either.

the cron.absent state also fails, always acting as if the cron job doesn't exist, when actually it does.

Setup

Plain default out-of-the-box salt 2019.2.1 on Debian 10

Steps to Reproduce Issue

Create a new cron job, this part will work...
` sudo salt "debian-salt-minion" cron.set_special jamesp '@hourly' 'date >> ~/crontest.log' identifier="TESTJOB"

Now try to delete it, this part will do nothing

sudo salt "debian-salt-minion" cron.rm_special jamesp '@hourly' 'date >> ~/crontest.log' identifier="TESTJOB"

The job will not be removed. You can verify with

sudo salt "debian-salt-minion" cron.ls jamesp

It doesn't matter if you use rm_job or rm_special
It doesn't matter if the job is for root or for some other user
It doesn't matter if you set an identifier or not

I have not been able to find any combination of arguments that can successfully remove any cron job

### Versions Report

Salt Version:
Salt: 2019.2.1

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.7.3
docker-py: Not Installed
gitdb: 2.0.5
gitpython: 2.1.11
ioflo: Not Installed
Jinja2: 2.10
libgit2: 0.27.7
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: 2.19
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: 0.27.4
Python: 3.7.3 (default, Apr 3 2019, 05:39:12)
python-gnupg: Not Installed
PyYAML: 3.13
PyZMQ: 17.1.2
RAET: Not Installed
smmap: 2.0.5
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.3.1

System Versions:
dist: debian 10.1
locale: UTF-8
machine: x86_64
release: 4.19.0-6-amd64
system: Linux
version: debian 10.1
```

[arizvisa]

@James00001, any logs? Do cron.raw_cron work, and cron.list_tab work at all?

You can add -ldebug to salt-call to get more verbose logs. You should see it trying to execute crontab at the very least. Something like salt-call -ldebug --local cron.raw_cron.

[James00001]

@arizvisa

cron.raw_cron and cron.list_tab both seem to work perfectly

With further testing, I figured out what is causing this bug. (or at least what condition triggers it, and how to work around it)

I had been getting a warning like this:

[WARNING ] /usr/lib/python3/dist-packages/salt/transport/zeromq.py:42: VisibleDeprecationWarning: zmq.eventloop.minitornado i
s deprecated in pyzmq 14.0 and will be removed.
    Install tornado itself to use zmq with the tornado IOLoop.

  import zmq.eventloop.ioloop

Everything else other than the cron module was working perfectly, so I didn't pay enough attention to it at first.

After doing apt-get install python3-tornado and restarting salt-master, the problem vanished, and cron.rm_job and cron.rm_special now seem to work again.

Perhaps this is just a bug in the sense that the deprecation of minitornado should be an "ERROR" instead of a "WARNING"? Perhaps a dependency on tornado needs to be declared?

[arizvisa]

Hmm. Weird. Yeah, those commands are literally executing crontab and filtering its output to do their dirty work, so if they're failing its either an issue w/ getting crontab output, or the filtering part.

I guess we'll let a maintainer figure out what the best course of action for this is then.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[arizvisa]

This needs to be triaged.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[xeacott]

Although I can investigate this, I'm going to ping @dwoz on this since he has more tornado experience than I - he may be able to shed some light on the dep warning...

[xeacott]

I can confirm that rm_special isn't removing the cron job too.