Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cron.rm_job and cron.rm_special do nothing (state cron.absent also broken) #55078

Open
James00001 opened this issue Oct 21, 2019 · 8 comments
Open
Labels
Bug broken, incorrect, or confusing behavior severity-high 2nd top severity, seen by most users, causes major problems

Comments

@James00001
Copy link

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
Copy link
Contributor

@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
Copy link
Author

@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
Copy link
Contributor

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.

@waynew waynew added this to Needs triage in [Test] Triage Dec 12, 2019
@stale
Copy link

stale bot commented Jan 7, 2020

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.

@stale stale bot added the stale label Jan 7, 2020
@arizvisa
Copy link
Contributor

arizvisa commented Jan 7, 2020

This needs to be triaged.

@stale
Copy link

stale bot commented Jan 7, 2020

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

@stale stale bot removed the stale label Jan 7, 2020
@xeacott
Copy link
Contributor

xeacott commented Jan 13, 2020

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 xeacott added Bug broken, incorrect, or confusing behavior P4 Priority 4 and removed needs-triage labels Jan 13, 2020
@xeacott
Copy link
Contributor

xeacott commented Jan 13, 2020

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

@xeacott xeacott added this to the Approved milestone Jan 13, 2020
@sagetherage sagetherage removed the P4 Priority 4 label Jun 3, 2020
@sagetherage sagetherage added Phosphorus v3005.0 Release code name and version severity-high 2nd top severity, seen by most users, causes major problems labels Jun 16, 2021
@sagetherage sagetherage modified the milestones: Approved, Phosphorus Jun 16, 2021
@Ch3LL Ch3LL removed the Phosphorus v3005.0 Release code name and version label Mar 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-high 2nd top severity, seen by most users, causes major problems
Projects
No open projects
[Test] Triage
  
Needs triage
Development

No branches or pull requests

7 participants