Re: Start of systemd timers after install/update of a package
On 01/24/2013 11:53 PM, Lennart Poettering wrote: a) list them in the %systemd_post rpm macro (and the other macros too) like you would do for service units. Note that %systemd_post and friends take an arbitrary amount of unit names. To enable these timer units by default, you'd also need to get them listed in the fedora preset files. Hmm if that is the case it probably is better that each package ships it's own preset file snipped which will enabled/disable relevant units that package ships. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/25/2013 06:26 AM, Adam Williamson wrote: I can't find it, but isn't there something in the guidelines which says you don't need an explicit dependency on anything that's part of @core? Making the assumption that the core comps never changes and having packages depend on that makes no sense to me. In the case of rsyslog which is not necessary any more, changes will need to be made to roughly 600 components ( I think there where like 3 packages that depended on it ) and those 61 packages that makes no sense migrating to native systemd times units should be made dependent on cron since it is technically not needed anymore. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/24/2013 06:30 PM, Jóhann B. Guðmundsson wrote: On 01/24/2013 04:28 PM, Bill Nottingham wrote: Tomas Mraz (tm...@redhat.com) said: On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. I'm somewhat skeptical of the benefit of migration in general. I'm really skeptical that the place you start reducing the dependency load is inn. I have started looking into migration of cron jobs to native systemd time units as I mentioned I would do with fesco on the last meeting. Out of the total 99 cron job the distribution ship there are 38 which come with service related packages thus might be applicable to migration from my pov the rest should just be left as is. What surprised me the most was that none of those components packages depended on cron which was the same thing with rsyslog when I looked into that which is what I expected they would do. Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? JBG It's a problem of incorrect dependencies. Many packagers simply don't require packages, which are in base group. I found out, when I removed vixie-cron provides and there were still packages, which had it wrong. I was forced to remove requirement on rsyslog, because some people wanted to install system without any logger. I guess I should ask FPC for a guideline, but as I do not have time for review of all packages, which incorrectly provide/require package I didn't do it. What is the added value of migration of cron jobs? I, as maintainer of cron, obviously don't see the added value. What might be interesting would be converting cron.daily jobs as systemd task. If systemd could execute daily job in time, when system load is low, that would be awesome. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Fri, Jan 25, 2013 at 03:46:34PM +0100, Marcela Mašláňová wrote: What is the added value of migration of cron jobs? I, as maintainer of cron, obviously don't see the added value. What might be interesting would be converting cron.daily jobs as systemd task. If systemd could execute daily job in time, when system load is low, that would be awesome. If that were done, how easy would it be for system administrators who need these jobs to actually run at a specific time to adjust that? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Fri, Jan 25, 2013 at 12:53:02AM +0100, Lennart Poettering wrote: c) Or you could list them as Wants= dependency in your service unit's [Service] section. That means that whenever your service unit is started, your time unit is too. No need for preset file changes. I think c) is the best choice if it makes little sense to ever run the service without the timer unit. It makes things very robust. In this case, if the service is disabled (masked, in the new terminology), would the timer still run, or does an inverse relationship need to also be spelled-out? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/25/2013 02:46 PM, Marcela Mašláňová wrote: What is the added value of migration of cron jobs? I, as maintainer of cron, obviously don't see the added value. What might be interesting would be converting cron.daily jobs as systemd task. If systemd could execute daily job in time, when system load is low, that would be awesome. There is no need to migrate any cron jobs that do not come with services/daemon ( hence only 38 packages ). The added value for example is you dont have to depend on extra packages ( since you already have dependency on systemd ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/25/2013 03:19 PM, Matthew Miller wrote: If that were done, how easy would it be for system administrators who need these jobs to actually run at a specific time to adjust that? You alter the time units the same way you alter any service unit ( same hurdle ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Fri, 25.01.13 08:36, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 01/24/2013 11:53 PM, Lennart Poettering wrote: a) list them in the %systemd_post rpm macro (and the other macros too) like you would do for service units. Note that %systemd_post and friends take an arbitrary amount of unit names. To enable these timer units by default, you'd also need to get them listed in the fedora preset files. Hmm if that is the case it probably is better that each package ships it's own preset file snipped which will enabled/disable relevant units that package ships. That's a clear no. Preset files shall never be shipped by their own packages. That defeats their point. If you have a unit file that you are sure should be unconditionally enabled, then enable them via a .wants/ link /usr, rather than in /etc. But really, we do that for very few services only, and we shouldn't do that for timer units either really, as that only leaves masking as a way for the admin to disable these units. I am pretty sure the Also= link in a service units' [Install] section is the best way to go for most packages. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Fri, 25.01.13 10:25, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Jan 25, 2013 at 12:53:02AM +0100, Lennart Poettering wrote: c) Or you could list them as Wants= dependency in your service unit's [Service] section. That means that whenever your service unit is started, your time unit is too. No need for preset file changes. I think c) is the best choice if it makes little sense to ever run the service without the timer unit. It makes things very robust. In this case, if the service is disabled (masked, in the new terminology), would the timer still run, or does an inverse relationship need to also be spelled-out? Masking makes a unit entirely unavailable to the system, and that includes its dependencies. It does make sense however for the timer unit to carry a BindTo= for the service unit it belongs to, so that the timer unit goes away automatically when the service unit is stopped. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/25/2013 06:32 PM, Lennart Poettering wrote: That's a clear no. Preset files shall never be shipped by their own packages. That defeats their point. Then timer units should always be enabled in the preset config JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/24/2013 04:03 PM, Jochen Schmitt wrote: The service was not started after the configure period was expired. Was the timer unit active? What does systemctl status yourunit.timer show? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
Tomas Mraz (tm...@redhat.com) said: On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. I'm somewhat skeptical of the benefit of migration in general. I'm really skeptical that the place you start reducing the dependency load is inn. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Thu, Jan 24, 2013 at 04:53:01PM +0100, Michal Schmidt wrote: Was the timer unit active? What does systemctl status yourunit.timer show? I think, this is a good hint, systemctl status innd-expire.timer told me something like Active: inactive... After I have done a # systemctl start innd-expire.timer I have got a Active: active (waiting) since ... So I assume the resolution is to add a systemctl start/try-restart forbar.timer in the post and postun scriptlets. A additonal question of this expirience is, how does systemd determinate that a timer should be active after boot. As a conclusion of my expiriences, I think we need anythin as a guideline for this topic. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/24/2013 04:28 PM, Bill Nottingham wrote: Tomas Mraz (tm...@redhat.com) said: On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. I'm somewhat skeptical of the benefit of migration in general. I'm really skeptical that the place you start reducing the dependency load is inn. I have started looking into migration of cron jobs to native systemd time units as I mentioned I would do with fesco on the last meeting. Out of the total 99 cron job the distribution ship there are 38 which come with service related packages thus might be applicable to migration from my pov the rest should just be left as is. What surprised me the most was that none of those components packages depended on cron which was the same thing with rsyslog when I looked into that which is what I expected they would do. Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/24/2013 05:31 PM, Jochen Schmitt wrote: On Thu, Jan 24, 2013 at 04:53:01PM +0100, Michal Schmidt wrote: Was the timer unit active? What does systemctl status yourunit.timer show? I think, this is a good hint, systemctl status innd-expire.timer told me something like Active: inactive... After I have done a # systemctl start innd-expire.timer I have got a Active: active (waiting) since ... So I assume the resolution is to add a systemctl start/try-restart forbar.timer in the post and postun scriptlets. A additonal question of this expirience is, how does systemd determinate that a timer should be active after boot. As a conclusion of my expiriences, I think we need anythin as a guideline for this topic. Yeah the packaging part of this has not been sorted out yet. I was going to migrated couple of cron jobs and do some local testing before proposing something to FPC JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Thu, Jan 24, 2013 at 05:30:52PM +, Jóhann B. Guðmundsson wrote: What surprised me the most was that none of those components packages depended on cron which was the same thing with rsyslog when I looked into that which is what I expected they would do. Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? Generally, the packages function without cron, so including a hard dependency might be overkill. An alternative would be to split the cron tasks into subpackages, but that too may seem like work in search of a real problem. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On 01/24/2013 05:41 PM, Matthew Miller wrote: On Thu, Jan 24, 2013 at 05:30:52PM +, Jóhann B. Guðmundsson wrote: What surprised me the most was that none of those components packages depended on cron which was the same thing with rsyslog when I looked into that which is what I expected they would do. Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? Generally, the packages function without cron, so including a hard dependency might be overkill. An alternative would be to split the cron tasks into subpackages, but that too may seem like work in search of a real problem. Sorry not following where do we draw the limit in that case? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Thu, Jan 24, 2013 at 06:38:35PM +, Jóhann B. Guðmundsson wrote: Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? Generally, the packages function without cron, so including a hard dependency might be overkill. An alternative would be to split the cron tasks into subpackages, but that too may seem like work in search of a real problem. Sorry not following where do we draw the limit in that case? Right about *there*, apparently. If you think it should be different, a suggestion for the packaging rules is probably in order. But I don't think packagers make a judgement call based on the requirements of their own package is a terrible starting point. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Thu, 24.01.13 16:03, Jochen Schmitt (joc...@herr-schmitt.de) wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. For timer units the same rules generally apply as for service units. To make sure they are enabled after boot you have two optins: a) list them in the %systemd_post rpm macro (and the other macros too) like you would do for service units. Note that %systemd_post and friends take an arbitrary amount of unit names. To enable these timer units by default, you'd also need to get them listed in the fedora preset files. b) Or you include them in the Also= field of your service unit's [Install] section. That means that whenever your service unit is enabled/disabled your timer unit is too. If you use this no addition to the preset files should be necessary. c) Or you could list them as Wants= dependency in your service unit's [Service] section. That means that whenever your service unit is started, your time unit is too. No need for preset file changes. I think c) is the best choice if it makes little sense to ever run the service without the timer unit. It makes things very robust. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
Le jeudi 24 janvier 2013 à 17:30 +, Jóhann B. Guðmundsson a écrit : On 01/24/2013 04:28 PM, Bill Nottingham wrote: Tomas Mraz (tm...@redhat.com) said: On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. I'm somewhat skeptical of the benefit of migration in general. I'm really skeptical that the place you start reducing the dependency load is inn. I have started looking into migration of cron jobs to native systemd time units as I mentioned I would do with fesco on the last meeting. Out of the total 99 cron job the distribution ship there are 38 which come with service related packages thus might be applicable to migration from my pov the rest should just be left as is. What surprised me the most was that none of those components packages depended on cron which was the same thing with rsyslog when I looked into that which is what I expected they would do. Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? From a packaging point of view, they should depend on crontabs, because this is the package that provides /etc/cron.daily/ among others. ( ie https://fedoraproject.org/wiki/Packaging:UnownedDirectories ) And crontabs pull cronie. Now, I am not sure that all packages work correctly out of the box without cron. Mlocate for example kinda need it ( as the database is not updated without it, so that's less useful.. ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
On Thu, 2013-01-24 at 17:30 +, Jóhann B. Guðmundsson wrote: On 01/24/2013 04:28 PM, Bill Nottingham wrote: Tomas Mraz (tm...@redhat.com) said: On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. I'm somewhat skeptical of the benefit of migration in general. I'm really skeptical that the place you start reducing the dependency load is inn. I have started looking into migration of cron jobs to native systemd time units as I mentioned I would do with fesco on the last meeting. Out of the total 99 cron job the distribution ship there are 38 which come with service related packages thus might be applicable to migration from my pov the rest should just be left as is. What surprised me the most was that none of those components packages depended on cron which was the same thing with rsyslog when I looked into that which is what I expected they would do. Maybe it's just me but is there not something more broken/alarming with that or is just me and this is just acceptable from packaging standpoint? I can't find it, but isn't there something in the guidelines which says you don't need an explicit dependency on anything that's part of @core? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
