Created attachment 675591 [details] patch to modify spec file Description of problem: yum-cron still uses legacy init scripts Version-Release number of selected component (if applicable): 0.9.2-6.fc19 How reproducible: 100% Steps to Reproduce: 1. check systemd for yum-cron.service 2. don't find it Actual results: not in systemd Expected results: in systemd Additional info:
Created attachment 675592 [details] yum-cron.service systemd unit file for yum-cron
Yes, this is needed, and thanks to your patch, should be fairly simple to implement. However, yum-cron has been subsumed into the main yum package, so I can't make the change: reassigned to the yum package maintainer instead, so he can do it.
Well, tried to re-assign to Zdenek, but bugzilla didn't take that change. Added him to the CC list instead: James or Zdenek, could you please change the default assignee of the yum-cron component to the appropriate person? Thanks!
Ported the patch to current HEAD, please review: http://lists.baseurl.org/pipermail/yum-devel/2013-January/009850.html
The [service] definition in the serivce file posted seems to be broken (assumes a long running daemon), changing it to: type=oneshot RemainAfterExit=true ...seems to make it work. Also there is no conversion, so any installed+working yum-cron services will switch off after upgrade ... I _think_: if [ -f /var/lock/subsys/yum-cron -a -f /etc/rc.d/init.d/yum-cron ]; then systemctl enable yum-cron fi ...will dtrt, but not tested atm. as I'd already moved all my machines to the newer yum-cron. Any comments?
Also we need to find out how to make "systemctl preset yum-cron" be enabled.
(In reply to comment #6) > Also we need to find out how to make "systemctl preset yum-cron" be enabled. What exactly is the purpose of this initscrip mean why is it needed as opposed to just run as a regular cron job since this looks awfully like a hack and the moodle maintainer duplicated this + it seems to be the underlying bug of #909720 ) We also have systemd timer units this could be migrated to ( if applicable ) and you will need to file a request against systemd for it to be added to the preset file
(In reply to comment #1) > Created attachment 675592 [details] > yum-cron.service > > systemd unit file for yum-cron If you are migrating unit files I kindly ask you to provide your name along with the bugs you file here [1] and have a look if those files have been already migrated which you can see here [2] before doing so. 1. http://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F19 2. http://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17
And I should mention as well that this ought to be a type oneshot unit not type simple...
(In reply to comment #7) > (In reply to comment #6) > > Also we need to find out how to make "systemctl preset yum-cron" be enabled. > > What exactly is the purpose of this initscrip mean why is it needed as > opposed to just run as a regular cron job since this looks awfully like a > hack and the moodle maintainer duplicated this + it seems to be the > underlying bug of #909720 ) So you can easily turn the service off, without having to uninstall the package > We also have systemd timer units this could be migrated to ( if applicable ) > and you will need to file a request against systemd for it to be added to > the preset file AIUI timer units shouldn't be used before at least F19, maybe F20 ... it's likely we'll move to them when they are available.(In reply to comment #9) (In reply to comment #9) > And I should mention as well that this ought to be a type oneshot unit not > type simple... Yeh, I said that in comment #5 and fixed it upstream and in rawhide.
(In reply to comment #10) > (In reply to comment #7) > > (In reply to comment #6) > > > Also we need to find out how to make "systemctl preset yum-cron" be enabled. > > > > What exactly is the purpose of this initscrip mean why is it needed as > > opposed to just run as a regular cron job since this looks awfully like a > > hack and the moodle maintainer duplicated this + it seems to be the > > underlying bug of #909720 ) > > So you can easily turn the service off, without having to uninstall the > package Disabling what service this is not a daemon you are running there, you mean disabling the cron job right? What exactly problem is that initscript trying to solve? > > > We also have systemd timer units this could be migrated to ( if applicable ) > > and you will need to file a request against systemd for it to be added to > > the preset file > > AIUI timer units shouldn't be used before at least F19, maybe F20 ... it's > likely we'll move to them when they are available.(In reply to comment #9) ? Timer units have been there since we pushed systemd into Fedora and have been usable since then. Lennarts feature request is just about them gaining calendar date support that's it The biggest feature of using timer units is to tie them to the startup of your daemon/service ( which this hack you are doing is not ) so when you effectively start up a daemon you "enable" the cron job which then get runs on what ever time interval it has been configured to run, then when you disable the daemon/service you effectively disable the cron job at the same.
The proper way for administrators to enable and disable this is literally touching and removing the /var/lock/subsys/yum-cron if they wanted to enable or disable this instead of using this initscript hack
Before everyone gets too wound up about the enabling style, I would like to point out that the current "hack" was made way back when yum was brand new, and before all these new, spiffier methods existed. The problem it was trying to solve was to provide an enable/disable means (short of uninstalling) consistent with the way everything else in the system was using. This was back in the days when "chkconfig" had just been stolen from IRIX and was viewed as the newest, spiffiest, cleanest way of doing things. And it worked, so there was no incentive to change it. Now that newer, spiffier, cleaner, more fashionable methods exist, just code them up instead of griping about it.
Ping? Has anyone tried to use timers for this?
I thought this was being deprecated in favour of comment 13 anyway doing so is not a big problem the question should just become if yum-cron should not then be deprecated since the yum cron script overlaps with the timer settings in the units? Give me sec and I'll post 4 units
Created attachment 777938 [details] yum-update.service
Created attachment 777939 [details] yum-update.timer
Created attachment 777940 [details] yum-cleanup.service
Created attachment 777941 [details] yum-cleanup.timer
Note I just threw this together it does not update with the parameters in the yum-cron script nor does it send mail ( which outputs probably would need do be fetch from the journal with this move )
Created attachment 788639 [details] systemd service file for use with the matching timer Based on Fedora 19, there is a more direct way of kicking off the yum-cron job. I've got a unit file for the service and the timer (but not for the 'hourly' job)
Created attachment 788641 [details] systemd timer file for use with the matching service
(In reply to jcpunk from comment #22) > Created attachment 788641 [details] > systemd timer file for use with the matching service Was that you that was working on this at flock? If not this might be taken care of already by the yum maintainers themselves
Nope, not me - I'm just a VERY interested party.
For the record, I am not aware of any yum developer working on this at Flock so it is possible that it was someone else who was very interested in this.
looks like there was work to get systemd and yum-cron into FC20. The Spec has entries for it, but the package doesn't seem to have built right to utilize it: http://koji.fedoraproject.org/koji/buildinfo?buildID=469738 yum_cron_systemd seems to have ended up as '0'
Looks like yum-cron installs systemd servies in yum-cron-3.4.3-114.fc21.noarch.rpm ( http://koji.fedoraproject.org/koji/buildinfo?buildID=477523 )