= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
Change owner(s): Jóhann B. Guðmundsson <johannbg AT gmail DOT com>
Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units.
== Detailed description == Add dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units in packages that already depend on systemd.
== Scope == * Policies and guidelines: ** Adjust packaging guidelines to fix dependency in cron packages [Package Cron Files 1] DONE ** Adjust packaging guidelines to mention migration of cron jobs to timer units for packages that already depend on systemd
* Fix spec files in packages that are not applicable for migration [Fix Cron Dependency Tracking Bug 2] * Review and migrate if applicable cron jobs shipped in packages that already depend on systemd [Timer Migration Tracking Bug 3] * Update systemd wikipage to contain timer units example
[1] https://fedoraproject.org/wiki/Packaging/CronFiles [2] https://bugzilla.redhat.com/show_bug.cgi?id=947037 [3] https://bugzilla.redhat.com/show_bug.cgi?id=991679 _______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
On Tue, Mar 04, 2014 at 03:32:03PM +0100, Jaroslav Reznik wrote:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
I'm in favor, but I think we could use a little bit more in the release notes -- at least a link to the systemd documentation and a quick note on how to override locally (although people should be getting used to this with systemd by now), and I think people would appreciate a list of services that were migrated.
On Mar 4, 2014 7:51 AM, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Tue, Mar 04, 2014 at 03:32:03PM +0100, Jaroslav Reznik wrote:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
I'm in favor, but I think we could use a little bit more in the release notes -- at least a link to the systemd documentation and a quick note on how to override locally (although people should be getting used to this
with
systemd by now), and I think people would appreciate a list of services
that
were migrated.
-- Matthew Miller -- Fedora Project -- mattdm@fedoraproject.org --
ACK. Upstream documentation is great, and the tracking bugs will give the list of affected packages. I can work with that.
--Pete
Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
== Scope ==
(Everyone), please keep the explicit "Proposal owners"/"other developers"/"release engineering"/"policies and guidelines" split. Other contributors *need* to know what they are being asked to do by your Change.
* Policies and guidelines:
** Adjust packaging guidelines to mention migration of cron jobs to timer
units for packages that already depend on systemd
Last time this was discussed in http://meetbot.fedoraproject.org/fedora-meeting/2013-02-06/fesco.2013-02-06-..., there were concerns about "confusion of users/admins", specifically referring to the disabling a .service / disabling a .socket duality. So we will need packaging guidelines not only for the migration, but for the timer units themselves.
(From the Change page:)
Administrators will have better time trigger in units compared to cron jobs like for example when administrator stops a service/daemon the timer unit will stop as well etc.
This would also seem to require detailed packaging guidelines for the timer units.
* Fix spec files in packages that are not applicable for migration [Fix Cron
Dependency Tracking Bug 2]
- Review and migrate if applicable cron jobs shipped in packages that
already depend on systemd [Timer Migration Tracking Bug 3]
How many packages (at least an of magnitude) are we talking about? Is it the 16+3 that are currently blocking the tracker bugs? Mirek
On 03/04/2014 02:54 PM, Miloslav Trmač wrote:
Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik <jreznik@redhat.com mailto:jreznik@redhat.com>:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
I'm not so sure this should be a system wide change since the migration it self affects less then half of total shipped cron jobs and for those that arent it only updates the components specfile to current packaging guidelines.
== Scope ==(Everyone), please keep the explicit "Proposal owners"/"other developers"/"release engineering"/"policies and guidelines" split. Other contributors /need/ to know what they are being asked to do by your Change.
Accept patches that's what I'm "asking" of them.
* Policies and guidelines: ** Adjust packaging guidelines to mention migration of cron jobs to timer units for packages that already depend on systemdLast time this was discussed in http://meetbot.fedoraproject.org/fedora-meeting/2013-02-06/fesco.2013-02-06-... , there were concerns about "confusion of users/admins", specifically referring to the disabling a .service / disabling a .socket duality. So we will need packaging guidelines not only for the migration, but for the timer units themselves.
Not following here we already have packaging guidelines for systemd units
(From the Change page:)
Administrators will have better time trigger in units compared to cron jobs like for example when administrator stops a service/daemon the timer unit will stop as well etc.This would also seem to require detailed packaging guidelines for the timer units.
* Fix spec files in packages that are not applicable for migration [Fix Cron Dependency Tracking Bug 2] * Review and migrate if applicable cron jobs shipped in packages that already depend on systemd [Timer Migration Tracking Bug 3]How many packages (at least an of magnitude) are we talking about? Is it the 16+3 that are currently blocking the tracker bugs? Mirek
To be clear not all cron jobs will be migrate, things like the drupal cron job "wget -O - -q -t 1 http://www.example.com/cron.php" wont be migrated since drupal does not depend on systemd and thus has no business being migrated but "mailman" cron job will be migrated since mailman ships a daemon hence unit and already depends on systemd so components that are applicable for migration due to their existing dependency on systemd are....
amavisd-new apt arm4 atop bcfg2 clement cyrus-imapd dbmail denyhosts dspam exim fetch-crl freeipa hylafax+ inn leafnode ltsp mailman mcelog mdadm mldonkey newscache nsd opendnssec openvas-scanner ovirt-engine ovirt-node polipo sagator sipwitch spamassassin squidGuard subscription-manager sysstat vdsm vnstat yum-cron
For the above components cron jobs will be manually inspected each and everyone *before* being decided if it will be migrated.
JBG
2014-03-04 18:34 GMT+01:00 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 03/04/2014 02:54 PM, Miloslav Trmač wrote:
Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
I'm not so sure this should be a system wide change since the migration it self affects less then half of total shipped cron jobs and for those that arent it only updates the components specfile to current packaging guidelines.
"System-wide" is defined "not self-contained", not "touching absolutely everything". It is likely appropriate in ths case.
* Policies and guidelines:
** Adjust packaging guidelines to mention migration of cron jobs to timer
units for packages that already depend on systemd
Last time this was discussed in http://meetbot.fedoraproject.org/fedora-meeting/2013-02-06/fesco.2013-02-06-..., there were concerns about "confusion of users/admins", specifically referring to the disabling a .service / disabling a .socket duality. So we will need packaging guidelines not only for the migration, but for the timer units themselves.
Not following here we already have packaging guidelines for systemd units
Those guidelines don't contain the word "timer" at all. Perhaps they are already sufficient; if so, that's not immediately obvious. Mirek
On 03/04/2014 05:42 PM, Miloslav Trmač wrote:
2014-03-04 18:34 GMT+01:00 "Jóhann B. Guðmundsson" <johannbg@gmail.com mailto:johannbg@gmail.com>:
On 03/04/2014 02:54 PM, Miloslav Trmač wrote:Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik <jreznik@redhat.com <mailto:jreznik@redhat.com>>: = Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-unitsI'm not so sure this should be a system wide change since the migration it self affects less then half of total shipped cron jobs and for those that arent it only updates the components specfile to current packaging guidelines."System-wide" is defined "not self-contained", not "touching absolutely everything". It is likely appropriate in ths case.
" Self contained changes
A self contained change is a change to isolated package(s), or a general changes with limited scope and impact on the rest of distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a SIG https://fedoraproject.org/w/index.php?title=SIG&action=edit&redlink=1 with limited impact outside the SIG's functional area. Self contained changes could be used for early idea state proposals for wider and complex changes."
I read this to a change that affect minimal number of packages ( which in this case is ca 40 - 50 ) out of 14k+ components as well as saying that self contained feature could be used for early idea state proposal for wider and complex changes which this be arguable be considered...
JBG
On Tue, 04.03.14 15:54, Miloslav Trmač (mitr@volny.cz) wrote:
Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
It is probably time to port over these jobs now. With systemd 209+ we should have a somewhat comprehensive solution in systemd now that can do roughly what cron can do, plus some nice additional features (though minus a couple of others).
I am looking into adding a couple of more things before the Fedora release, in order to make this functionality convincing enough that people can understand why this change is made. For example, I want support for timer events that can wake up the system, and simple anacron-like behaviour.
I'd also like to make sure we sell this properly. While I think it should be a goal to port all cronjobs we *ship* over to this, I want to make sure that cron is advertised as a good solution for people who just want to queue a simple cronjob. This is because setting up a timer service is more complex than setting up a cronjob. A cronjob is a single line added to "crontab -e" or /etc/crontab. However, a systemd timer unit will always be two files, and they will have 2+ lines each. While the systemd way is certainly more uniform with the rest of service management, it is definitely a bit more work, and I don't want to be in competition here...
Lennart
On Mar 4, 2014 10:52 AM, "Lennart Poettering" mzerqung@0pointer.de wrote:
On Tue, 04.03.14 15:54, Miloslav Trmač (mitr@volny.cz) wrote:
Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
It is probably time to port over these jobs now. With systemd 209+ we should have a somewhat comprehensive solution in systemd now that can do roughly what cron can do, plus some nice additional features (though minus a couple of others).
I am looking into adding a couple of more things before the Fedora release, in order to make this functionality convincing enough that people can understand why this change is made. For example, I want support for timer events that can wake up the system, and simple anacron-like behaviour.
I'd also like to make sure we sell this properly. While I think it should be a goal to port all cronjobs we *ship* over to this, I want to make sure that cron is advertised as a good solution for people who just want to queue a simple cronjob. This is because setting up a timer service is more complex than setting up a cronjob. A cronjob is a single line added to "crontab -e" or /etc/crontab. However, a systemd timer unit will always be two files, and they will have 2+ lines each. While the systemd way is certainly more uniform with the rest of service management, it is definitely a bit more work, and I don't want to be in competition here...
Lennart
-- Lennart Poettering, Red Hat --
Will there be a way for regular users to use timer units? User= will execute as a regular user, sure, but root still needs to set that up.
--Pete
On Tue, 04.03.14 11:27, Pete Travis (lists@petetravis.com) wrote:
I'd also like to make sure we sell this properly. While I think it should be a goal to port all cronjobs we *ship* over to this, I want to make sure that cron is advertised as a good solution for people who just want to queue a simple cronjob. This is because setting up a timer service is more complex than setting up a cronjob. A cronjob is a single line added to "crontab -e" or /etc/crontab. However, a systemd timer unit will always be two files, and they will have 2+ lines each. While the systemd way is certainly more uniform with the rest of service management, it is definitely a bit more work, and I don't want to be in competition here...
Will there be a way for regular users to use timer units? User= will execute as a regular user, sure, but root still needs to set that up.
Kinda no and kinda yes.
PID 1 will not do user jobs. However, systemd user instances will do that for you. However, they don't run unless you are logged in or have enabled lingering (with "loginctl set-linger"). The idea is that this is strictly opt-in, and unless enabled via set-linger the user cannot take up resources while not logged in. And if the the user is logged in (or set-linger is used), then it will not enable time-based actviation for it, but also other kinds of activation like .socket, and so on...)
So, we are different here, it's a lot more restricted, and you will have a per-user systemd instance around if you make use of this, but then again you get the real deal, not just timer based activation...
Lennart
----- Original Message -----
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
Change owner(s): Jóhann B. Guðmundsson <johannbg AT gmail DOT com>
Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units.
This change (as proposed here) is discontinued as Jóhann announced his intention to leave the project. The same applies for Sys V to systemd unit migration feature that spawns through several releases. Thanks for you work on it!
Both changes are free to pick up.
Jaroslav
On 05/20/2014 12:47 PM, Jaroslav Reznik wrote:
----- Original Message -----
= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
Change owner(s): Jóhann B. Guðmundsson <johannbg AT gmail DOT com>
Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units.
This change (as proposed here) is discontinued as Jóhann announced his intention to leave the project. The same applies for Sys V to systemd unit migration feature that spawns through several releases. Thanks for you work on it!
Both changes are free to pick up.
Apparently he forgot to mention the retraction of the sys V to systemd proposal in this mail as well as qoute my reason I guess somethings are two hard
" Greeting Jaroslav
With regrets I must say I feel we have grown so fat we are about to collapse under our own weight but instead of properly start dealing with that within the project, people chose to ignore that fact but instead chose to force some future vision of RHEL 8 upon the project under the names of .next, products and wg's and constantly attack the solid ground what our foundations have stood for and their meaning all those years and embark on multiproduct releases based on wrong fundamental assumption, without statistical backing up of what they considered being the underlying cause for some of their assumptions and without thoroughly thinking things through what needs to be done before being able to do that as well as the fact we lack the necessary community infrastructure and workflows being in place to remotely being able to achieve delivering multiple products in a useful and efficient manner based on the resources we have in the project.
And as WG's slowy turn into tiny little empires fighting amongst themselves for components directions and maintenance while the owners of those components are scratching their head still trying to figure how the .next,product and wg proposal affects them, their maintenance and where they general fit into that future vision or simply are ignoring it which inevitably will result in them suddenly finding themselves being slapped by reality and waking up from their slumber when it finally does hit them.
Unfortunately I'm not seeing much future or vision in Fedora and it's direction anymore and the fact is that I'm failing to convey what needs to be fixed in any useful and meaningful way and manner, with the end result being that I'm not being heard and at the same time being powerless in fixing things that need fixing within the community. makes me part of the problem not the solution for the project and those that still believe in it and the direction it is taking.
Thus I here by official request the withdrawal of both of my features, sys V to systemd migration as well cron to timer migration where applicable due to how those processes have been handled by FPC and FESCo and their members and their expectation as well as the fact that envision of Fedora all those what 8+ years is proving to be the boulevard of broken dreams of what I hoped we could accomplish and achieve together as an community under the naive and false assumption that Fedora was a community sponsored project not community corporate owned one.
My withdrawal should allow for those willing to continue with systemd migration and integration within the project submit *new proposal* to the feature process tailored to the expected and wanting of FESCo and FPC and continue the work that I'm leaving behind which is roughly above 1000 man hours by my estimations to properly integrate these things into the distribution.
Best regards Jóhann B."
Good luck with either Matt or Stephen as your new project leaders
JBG
Jóhann B. Guðmundsson wrote:
With regrets I must say I feel we have grown so fat we are about to collapse under our own weight but instead of properly start dealing with that within the project, people chose to ignore that fact but instead chose to force some future vision of RHEL 8 upon the project under the names of .next, products and wg's and constantly attack the solid ground what our foundations have stood for and their meaning all those years and embark on multiproduct releases based on wrong fundamental assumption, without statistical backing up of what they considered being the underlying cause for some of their assumptions and without thoroughly thinking things through what needs to be done before being able to do that as well as the fact we lack the necessary community infrastructure and workflows being in place to remotely being able to achieve delivering multiple products in a useful and efficient manner based on the resources we have in the project.
And as WG's slowy turn into tiny little empires fighting amongst themselves for components directions and maintenance while the owners of those components are scratching their head still trying to figure how the .next,product and wg proposal affects them, their maintenance and where they general fit into that future vision or simply are ignoring it which inevitably will result in them suddenly finding themselves being slapped by reality and waking up from their slumber when it finally does hit them.
Unfortunately I'm not seeing much future or vision in Fedora and it's direction anymore and the fact is that I'm failing to convey what needs to be fixed in any useful and meaningful way and manner, with the end result being that I'm not being heard and at the same time being powerless in fixing things that need fixing within the community. makes me part of the problem not the solution for the project and those that still believe in it and the direction it is taking.
I somewhat share your feelings about "Fedora Next", it serves no useful purpose and only makes things worse in many ways. Sad to see you go, but I can't really blame you. :-(
Kevin Kofler
devel@lists.stg.fedoraproject.org
-
Jaroslav Reznik -
Jóhann B. Guðmundsson -
Kevin Kofler -
Lennart Poettering -
Matthew Miller -
Miloslav Trmač -
Pete Travis