Bug 1040620 - yum-cron should use systemd
Summary: yum-cron should use systemd
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum
Version: 7.0
Hardware: All
OS: Linux
high
low
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: Karel Srot
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-11 17:31 UTC by jcpunk
Modified: 2014-06-18 05:18 UTC (History)
12 users (show)

Fixed In Version: yum-3.4.3-112.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 893593
Environment:
Last Closed: 2014-06-13 13:16:34 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description jcpunk 2013-12-11 17:31:58 UTC
+++ This bug was initially created as a clone of Bug #893593 +++

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:

--- Additional comment from  on 2013-01-09 09:46:30 EST ---

systemd unit file for yum-cron

--- Additional comment from Habig, Alec on 2013-01-09 11:05:54 EST ---

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.

--- Additional comment from Habig, Alec on 2013-01-09 11:09:07 EST ---

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!

--- Additional comment from Zdeněk Pavlas on 2013-01-14 03:20:59 EST ---

Ported the patch to current HEAD, please review:

http://lists.baseurl.org/pipermail/yum-devel/2013-January/009850.html

--- Additional comment from James Antill on 2013-02-06 16:51:40 EST ---

 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?

--- Additional comment from James Antill on 2013-02-06 17:05:11 EST ---

Also we need to find out how to make "systemctl preset yum-cron" be enabled.

--- Additional comment from Jóhann B. Guðmundsson on 2013-02-27 16:30:48 EST ---

(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

--- Additional comment from Jóhann B. Guðmundsson on 2013-02-27 16:32:52 EST ---

(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

--- Additional comment from Jóhann B. Guðmundsson on 2013-02-27 16:51:05 EST ---

And I should mention as well that this ought to be a type oneshot unit not type simple...

--- Additional comment from James Antill on 2013-02-28 11:14:38 EST ---

(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.

--- Additional comment from Jóhann B. Guðmundsson on 2013-02-28 12:19:41 EST ---

(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.

--- Additional comment from Jóhann B. Guðmundsson on 2013-02-28 12:27:00 EST ---

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

--- Additional comment from Habig, Alec on 2013-02-28 13:41:52 EST ---

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.

--- Additional comment from Orion Poplawski on 2013-07-24 14:27:42 EDT ---

Ping?  Has anyone tried to use timers for this?

--- Additional comment from Jóhann B. Guðmundsson on 2013-07-24 15:17:29 EDT ---

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

--- Additional comment from Jóhann B. Guðmundsson on 2013-07-24 15:22:41 EDT ---



--- Additional comment from Jóhann B. Guðmundsson on 2013-07-24 15:23:36 EDT ---



--- Additional comment from Jóhann B. Guðmundsson on 2013-07-24 15:25:35 EDT ---



--- Additional comment from Jóhann B. Guðmundsson on 2013-07-24 15:26:49 EDT ---



--- Additional comment from Jóhann B. Guðmundsson on 2013-07-24 15:31:33 EDT ---

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 )

--- Additional comment from  on 2013-08-20 16:32:26 EDT ---

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)

--- Additional comment from  on 2013-08-20 16:33:11 EDT ---



--- Additional comment from Jóhann B. Guðmundsson on 2013-08-20 16:36:35 EDT ---

(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

--- Additional comment from  on 2013-08-20 16:38:32 EDT ---

Nope, not me - I'm just a VERY interested party.

--- Additional comment from Jan Zeleny on 2013-08-21 02:29:20 EDT ---

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.

--- Additional comment from  on 2013-10-21 15:37:44 EDT ---

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'

--- Additional comment from  on 2013-11-11 15:37:03 EST ---

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 )

Comment 2 Zdeněk Pavlas 2014-01-23 12:48:24 UTC
There's a leftover fedora-specific block in yum.spec that disables yum_cron_systemd when building for rhel.  I'm sure this should be simply removed.  However, this fix has potentially a large impact and we're quite late.  given a low severity, postponing to 7.1.

--- a/yum.spec
+++ b/yum.spec
@@ -14,11 +14,6 @@
 BuildRequires: bash-completion
 %endif
 
-%if 0%{?fedora} <= 18
-# yum in Fedora <= 18 doesn't use systemd unit files...
-%define yum_cron_systemd 0
-%endif
-
 %if %{auto_sitelib}
 
 %{!?python_sitelib: %define python_sitelib %(python -c "from distutils.sysconfig import get_python_lib; print get_python_

Comment 3 Pat Riehecky 2014-01-23 14:18:14 UTC
I understand your concern about the potential impact.  However, I'm a bit concerned that a transition between 7.0 and 7.1 on this might create a great deal of confusion for the end users.  Switching from chkconfig to systemctl may confuse the workflow/puppet config/cfengine/etc.

Given the simplicity of the fix, I wonder if consistency for the whole lifecycle of yum-cron in RHEL7 might be worth revisiting this.

Comment 4 Zdeněk Pavlas 2014-01-23 15:30:34 UTC
The simple fix above seems to work (at least I can build and install it).  Ack'd.

Comment 5 Jan Zeleny 2014-01-23 15:39:15 UTC
The more important question: How about actually running it, does that work as well?

Comment 6 Pat Riehecky 2014-01-23 16:29:13 UTC
It works when I run it.  The behavior is exactly what I'd expect.

Comment 7 Jan Zeleny 2014-01-24 07:40:18 UTC
(In reply to Pat Riehecky from comment #6)
> It works when I run it.  The behavior is exactly what I'd expect.

And have you tried the package that Zdenek built and tried to install yesterday or was it some other package? It would help us to have a point of reference here. Thanks

Comment 9 Zdeněk Pavlas 2014-01-24 11:37:02 UTC
He probably built it locally with the patch from c#2, as did I.

Comment 11 Pat Riehecky 2014-01-27 13:54:39 UTC
Sorry for the late reply. Zdenek is correct, I used the patch from C#2

Comment 13 Ludek Smid 2014-06-13 13:16:34 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.