Bug 954375 - package logrotate is missing logrotate.service, logrotate.timer
package logrotate is missing logrotate.service, logrotate.timer
Status: RESOLVED FIXED
: 957039 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Basesystem
Leap 42.1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Pedro Monreal Gonzalez
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-10 02:12 UTC by Paul Pfeiffer
Modified: 2017-08-18 06:39 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Pfeiffer 2015-11-10 02:12:15 UTC
Package logrotate in Version 3.8.7-7.1 is missing the files:
logrotate.service 
logrotate.timer

These were present as of opensuse 13.2 .

The file logrotate.timer is required by the line:
enable logrotate.timer
in file /usr/lib/systemd/system-preset/90-default-openSUSE.preset of
package 
systemd-presets-branding-openSUSE-0.3.0-23.2.noarch .

Instead it is called via /etc/cron.daily/logrotate .

I guess this change (among others) from Changes is missing:"
- Migrate from cron to systemd timer units, this is overall 
  the most important package to migrate since it is one 
  of the very few base components that hard-require cron."

The package from Leap should be updated to latest in 13.2 (or)
"enable logrotate.timer" should be removed from /usr/lib/systemd/system-preset/90-default-openSUSE.preset .
Comment 1 Marcus Meissner 2015-11-10 07:11:44 UTC
logrotate is from sles12 ga on Leap, which was not yet ported to systemd.

There is however no conflict as far as I see, as the cron job will run.

The systemd presets are "optional", nothing will break if the service is not there.
Comment 2 Paul Pfeiffer 2015-11-10 11:25:56 UTC
I can confirm that there is no conflict.

There is only a lot of lines (during install) in the log:
systemd[1]: Cannot add dependency job for unit logrotate.timer, ignoring: Unit logrotate.timer failed to load: No such file or directory.

With some unrelated logging problem it took me some time to figure out why the file is missing. 
I thought somebody might have overseen that leap is not migrated here.

Is there some information about it on the web? Like what services get migrated back when upgrading 13.2->42.1 . Are there any plans for porting the rest to systemd in leap?

Are such cases handled via openfate?

I would have been happy if there would have been a line in the Release Notes.
Comment 3 Marcus Meissner 2015-11-10 14:01:40 UTC
it could also be  that some other package in its service requires this. i dont find one outright though.
Comment 4 Kristyna Streitova 2015-11-19 11:39:29 UTC
Adding Stephan Kulow to CC.

@coolo: Would you please be so kind and answer the questions about Leap from comment 2? Thanks in advance!
Comment 5 Stephan Kulow 2015-11-19 12:04:50 UTC
No, there is no such list - but I suppose switching logrotate in SLE12 to use systemd is something we should do. And then leap will get the same.
Comment 6 Kristyna Streitova 2015-11-23 16:34:55 UTC
(In reply to Stephan Kulow from comment #5)
> but I suppose switching logrotate in SLE12 to
> use systemd is something we should do. And then leap will get the same.


Yes, I agree. I created a SLE bug for it (bug 956303). As soon as SLE12 logrotate is migrated to systemd, Leap will get the same package.
Comment 7 Kristyna Streitova 2015-12-04 15:27:16 UTC
*** Bug 957039 has been marked as a duplicate of this bug. ***
Comment 8 Archie Cobbs 2016-04-13 16:54:54 UTC
Since this bug is not fixed yet, what is the recommended workaround in the meantime?
Comment 9 Kristyna Streitova 2016-04-14 14:00:28 UTC
(In reply to Archie Cobbs from comment #8)
> Since this bug is not fixed yet, what is the recommended workaround in the
> meantime?

As Marcus said in the comment 1, the absence of the systemd timer isn't critical. It only adds some "there is no such file" warnings. Therefore, there is no special workaround needed.
Comment 10 Archie Cobbs 2016-04-14 15:20:35 UTC
(In reply to Kristyna Streitova from comment #9)
> (In reply to Archie Cobbs from comment #8)
> > Since this bug is not fixed yet, what is the recommended workaround in the
> > meantime?
> 
> As Marcus said in the comment 1, the absence of the systemd timer isn't
> critical. It only adds some "there is no such file" warnings. Therefore,
> there is no special workaround needed.

OK thanks. What I meant was a workaround that stops the annoying messages (I get a text message every time one of my servers logs a warning to /var/log/warn).

Will this work? (I don't know the syntax for these files)

--- 90-default-openSUSE.preset.orig	2016-04-14 10:19:29.061551868 -0500
+++ 90-default-openSUSE.preset	2016-04-14 10:19:35.174795098 -0500
@@ -16,7 +16,7 @@
 enable iscsid.socket
 enable iscsi.service
 enable epmd.socket
-enable logrotate.timer
+#enable logrotate.timer
 enable haveged.service
 enable irqbalance.service
 enable auditd.service

Then what? systemctl daemon-reexec ?

Thanks.
Comment 11 Marcus Meissner 2016-04-14 15:23:28 UTC
you can just remove the line(s).

the presets are not evaluated only during package installation, no need for deaemon restart I would say.
Comment 12 andreas bittner 2016-05-31 15:39:38 UTC
Is this bug going anywhere? Is leap 42.1 gonna get a properly working logrotate? I am seeing lot loglines and pollution about this logrotate stuff not working



May 31 17:33:10 tux01 systemd[1]: Cannot add dependency job for unit logrotate.timer, ignoring: Unit logrotate.timer failed to load: No such file or directory.


42.1 (came from previous 13.2 or maybe even earlier).

Thanks.
Comment 14 Per Jessen 2017-08-18 06:39:36 UTC
opensuse Leap 421 has reached end-of-life and is no longer being maintained.  As of Leap423, logrotate moved from being cron-driven to a systemd timer, and now includes the logrotate.service and logrotate.timer units. 
The timer still needs being activated though, see bug#1054353