Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Thu, 30.10.14 00:27, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: Is systemctl daemon-reload really synchronous, or does it return before the reload if effectively done ? (I saw the --no-block argument that make me fear this) It is synchronous. --no-block mostly applies to start and stop and suchlike, i.e. operations that involve jobs, which daemon-reload really doesn't. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
Le mercredi 22 octobre 2014, 13:07:39 Lennart Poettering a écrit : So, I thought myself a couple of times about adding a cron generator upstream, but always came to the conclusion that having to load the configuration **twice** during boot-up would be suboptimal. Well, you can order your reload service After=local-fs.target, which should do the trick. As /var might be subdivided into more submounts you really want to order after local-fs.target, and nothing earlier. Ok, thanks, I have it mostly solved now. I have my generator check for /var/spool... and writing a service in /run to call itself again **only** if needed. On the second run of the generator, this service is not generated again, it just vanish; it acts like a transient unit. So, on systems with /var in /, it run once; and on systems with a separate /var, it run twice. It is set to run After=local-fs.target and Before=cron.target The only remaining problem is that the added timer is not started. Is systemctl daemon-reload really synchronous, or does it return before the reload if effectively done ? (I saw the --no-block argument that make me fear this) ● cron-after-var.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) since jeu 2014-10-30 00:00:39 CET; 13min ago Main PID: 370 (code=exited, status=0/SUCCESS) ● cron-tchet-tchet-0.timer - [Cron] 40 8 * * * /home/tchet/.ben/ben.sh Loaded: loaded (/var/spool/cron/crontabs/tchet) Active: inactive (dead) Docs: man:systemd-crontab-generator(8) https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L405 Alexandre Detiste___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-cron: retrigger generator after /var is mounted
Hi, I have been maitaining systemd-crontab-generator for some months, this is a generator developped outside of systemd that translates the crontabs in timer service units. I have two unresolved bugs in our tracker that I don't know how to tackle in the most systemd-way. Maybe you know better. Here they are: https://github.com/systemd-cron/systemd-cron/issues/26 -) how can I trigger a rerun of the generator after /var is mounted. There is already a trigger on PathChanged=/var/spool/cron/crontabs, but this doens't work, because cron.target is started after /var is mounted. I already noticed the presence of /run/systemd/generator/var.mount; but I don't know how to glue it together. Current trigger units: https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in --- https://github.com/systemd-cron/systemd-cron/issues/12 - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown, it is not restarted on next reboot. --- Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wed, 22.10.14 09:56, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: Hi, I have been maitaining systemd-crontab-generator for some months, this is a generator developped outside of systemd that translates the crontabs in timer service units. I have two unresolved bugs in our tracker that I don't know how to tackle in the most systemd-way. Maybe you know better. Here they are: https://github.com/systemd-cron/systemd-cron/issues/26 -) how can I trigger a rerun of the generator after /var is mounted. generators are rerun if you issue systemctl daemon-reload There is already a trigger on PathChanged=/var/spool/cron/crontabs, but this doens't work, because cron.target is started after /var is mounted. I already noticed the presence of /run/systemd/generator/var.mount; but I don't know how to glue it together. Current trigger units: https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in So, I thought myself a couple of times about adding a cron generator upstream, but always came to the conclusion that having to load the configuration twice during boot-up would be suboptimal. The scheme I'd hence propose is a different one: it's OK to cover /etc/cron.daily and friends natively with a generator (and that's easy as the stuff is in /etc), but for the per-user stuff stored in /var it is a better idea to just leave traditional crond around, however, with one trick: only start it as soon as there is a file dropped into the cron subdir in /var. This way, users can use cron as they always did: as long as they did not install any user cronjobs everything works fine without crond started, and then when they install user cronjobs crond magically gets started in the background. The way how users install cronjobs is by invoking crontab -e anyway, and that tool needs to be installed anyway of the crond package, hence installing crond in a way that it is triggered via a crond.path unit should be OK too. Hope that makes sense? https://github.com/systemd-cron/systemd-cron/issues/12 - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown, it is not restarted on next reboot. Hmm, could you file a bug about this issue on fdo bz? we should probably cover for this nicely. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 09:44 AM, Lennart Poettering wrote: So, I thought myself a couple of times about adding a cron generator upstream As far as I can tell generators serve only one purpose and that is to bridge an gap to allow users of consumers of systemd to migrate to it's native format hence I thought that we would only support one native systemd format hence generator for distro-specific or alternative components ( be it cron, be it ifcfg files etc ) to what we provide would be created and handled by downstream or whomever else requires it. Or to put this differently we will not create. come up with, ship ( and thus support those ) generators but expect consumers of systemd to use systemd and it's format natively in their environment. Alexandre why did you decide to write that generate to begin with? Why not migrate what needs to be migrated to native system timer formats for those relevant component and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote: On 10/22/2014 09:44 AM, Lennart Poettering wrote: So, I thought myself a couple of times about adding a cron generator upstream As far as I can tell generators serve only one purpose and that is to bridge an gap to allow users of consumers of systemd to migrate to it's native format I don't think this is correct. Take, for example, gpt-auto-generator, efi-boot-generator, hibernate-resume-generator... Also, systemd.mount(5) page states: In general, configuring mount points through /etc/fstab is the preferred approach. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
-) how can I trigger a rerun of the generator generators are rerun if you issue systemctl daemon-reload I already know, this is what our trigger unit does. https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in ... after /var is mounted. this is the point I didn't get right. Would linking cron-update.service in new folder (/usr)/lib/systemd/system/var.mount.wants/ do the trick ? I currently start it from /etc/rc.local it's OK to cover /etc/cron.daily and friends natively with a generator The issue with a generator is there must be some name mangling to ensure that the units have an unique name and unit name like 'cron-root-13.timer' in systemctl list-timers are not user friendly. (we use now cron-$filename-$userid-$pkey.timer ) That is why cron.hourly|daily|weekly ... are provided as static units that can be safely referenced in man pages; this way systemd-cron can even work with an empty /etc/crontab . (and that's easy as the stuff is in /etc), but for the per-user stuff stored in /var it is a better idea to just leave traditional crond around, however, with one trick: only start it as soon as there is a file dropped into the cron subdir in /var. This way, users can use cron as they always did: as long as they did not install any user cronjobs everything works fine without crond started, and then when they install user cronjobs crond magically gets started in the background. The way how users install cronjobs is by invoking crontab -e anyway, and that tool needs to be installed anyway of the crond package, hence installing crond in a way that it is triggered via a crond.path unit should be OK too. Hope that makes sense? That makes sense, but I'm not responsible for packaging 'cron' in Debian; that must also work for sysvinit. I doubt someone will like this halfhalf solution. The crontab shipped with systemd-cron is written in python and can't be setgid like the real crontab; so I asked if vixie-crontab could be shipped in an extra standalone package, but I don't expect much more. - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown, it is not restarted on next reboot. Hmm, could you file a bug about this issue on fdo bz? we should probably cover for this nicely. https://bugs.freedesktop.org/show_bug.cgi?id=85321 Ok it's done, it would benefit native units too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wed, 22.10.14 14:48, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote: On 10/22/2014 09:44 AM, Lennart Poettering wrote: So, I thought myself a couple of times about adding a cron generator upstream As far as I can tell generators serve only one purpose and that is to bridge an gap to allow users of consumers of systemd to migrate to it's native format I don't think this is correct. Take, for example, gpt-auto-generator, efi-boot-generator, hibernate-resume-generator... Correct. It's a way how to convert other runtime or static configuration into native configuration. A primary usecase for that is compat, but other runtime parameters are not like that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wed, 22.10.14 13:03, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: -) how can I trigger a rerun of the generator generators are rerun if you issue systemctl daemon-reload I already know, this is what our trigger unit does. https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in ... after /var is mounted. this is the point I didn't get right. Would linking cron-update.service in new folder (/usr)/lib/systemd/system/var.mount.wants/ do the trick ? Well, you can order your reload service After=local-fs.target, which should do the trick. As /var might be subdivided into more submounts you really want to order after local-fs.target, and nothing earlier. I currently start it from /etc/rc.local Yuck! Tha'ts more or less obsolete, and is only supported (in a limited way) for compat. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
Or to put this differently we will not create. come up with, ship ( and thus support those ) generators but expect consumers of systemd to use systemd and it's format natively in their environment. Alexandre why did you decide to write that generate to begin with? Hi, I've been using the systemd-cron Debian package since 2013/10 to take care of /etc/cron.daily/ I soon noticed it wasn't processing the crontabs , I added a symlink on /etc/cron.weekly/ to emulate the one I cared about and forgot about it. Then in june there was a bug filled to remove the Provides: cron-daemon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 This prompted me to find a better solution. Konstantin Stepanov and Why not migrate what needs to be migrated to native system timer formats for those relevant component and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? The rest ? The generator can now handle all possible cases JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 11:16 AM, Alexandre Detiste wrote: Why not migrate what needs to be migrated to native system timer formats for those relevant component and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? The rest ? The generator can now handle all possible cases You did not answer my question. Why dont you migrate the components depending on the core/baseOS and ship cron jobs to native systemd timer units ( and upstream them in the process ) and leave the rest up to the traditional daemons to handle? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
(sorry mail fired up too soon) Or to put this differently we will not create. come up with, ship ( and thus support those ) generators but expect consumers of systemd to use systemd and it's format natively in their environment. Alexandre why did you decide to write that generate to begin with? Hi, I didn't wrote it. I've been using the systemd-cron Debian package since 2013/10 to take care of /etc/cron.daily/ I soon noticed it wasn't processing the crontabs , I added a symlink on /etc/cron.weekly/ to emulate the one I cared about and forgot about it. Then in june there was a bug filled to remove the Provides: cron-daemon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 This virtual package cron-daemon act as a gear box that lets users switch at their will from one cron daemon to another. It documents a specific interface ( /etc/crontab , /etc/cron.*/ ...) Without this Provides:, systemd-cron would had been useless. This prompted me to find a better solution. Konstantin Stepanov (https://github.com/kstep/systemd-crontab-generator) and Dwayne bent (static units, build infrastructure) kindly agreed to let me merge their respective projects to get a full feature systemd-cron package. Then I went on with development. Why not migrate what needs to be migrated to native system timer formats for those relevant component I have no power over this. and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? The rest ? The generator can now handle all possible cases; it just doesn't send emails like cron; but that will remain an wontfix I guess. Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
Why not migrate what needs to be migrated to native system timer formats This would be the responsability of each individual package manager; after some policy would have mandated it and it's too late before the release freeze. Debian only ships exaclty one timer now: systemd-tmpfiles-clean.timer This may evolve next year after Jessie is released. I would then adapt systemd-cron not to process /etc/cron.d/$(package) if (/usr)/lib/systemd/system/$(package).timer exists . I'll asks what the others downstreams (Arch...) think of it; if it might already be implented that way. Alexandre ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 11:26 AM, Alexandre Detiste wrote: it just doesn't send emails like cron; but that will remain an wontfix I guess. Systemd itself does not send email but you can configure the timer units ( the service part ) to do so when they fail via OnFailure=trigger custom email script but you have to do so individually per timer's service units ( you cannot define that Onfailure= behaviour default for all units or just timer units ) . That takes care of failed starting timer jobs which is how I'm accustom to receive notifications from cron ( there seems to be split in practical sense of this as in those that only want to get email when things fail to run and those that always want to get email regardless if they failed to run or not ) The always part you handle in the script being run or via another Exec* line I would recommend you to label the timer in the journal as well for quick searching only for relevant timer info ExecStart=/bin/systemd-cat -t MY TIMER JOB LABEL /usr/bin/$FOO whatever Then run ( or script for email ) something like journalctl SYSLOG_IDENTIFIER=MY TIMER JOB LABEL Which will output you just the info you need. Arguable we should always label timer units in the journal which in turn would take care of that usability bug where users complain about timers being to noisy in log but Lennart can comment on that if he considers that viable solution for that bug. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 11:51 AM, Alexandre Detiste wrote: Why not migrate what needs to be migrated to native system timer formats This would be the responsability of each individual package manager; after some policy would have mandated it and it's too late before the release freeze. Debian only ships exaclty one timer now: systemd-tmpfiles-clean.timer This may evolve next year after Jessie is released. I would then adapt systemd-cron not to process/etc/cron.d/$(package) if (/usr)/lib/systemd/system/$(package).timer exists . I'll asks what the others downstreams (Arch...) think of it; if it might already be implented that way. In Fedora we had 100 components that shipped cron jobs of some short, out of those, 50 components depend on systemd and then there was further filter due to things not being legacy and no longer used or simply not beneficial to be migrated ( It would just cause administrative nuance in doing so and those 50 jobs or so would have been less for every distro to worry about but I got fedup with how things where handled so I abandoned that feature of mine after correcting the dependence of those 50 components that would definitely not be migrated ) so as I say you should easily be able to migrate that stuff since I dont expect Debian shipping much more than that and well before Jessie gets released, especially now since Ian seems to be keen on misusing the GR process ( and delay the release even further as an result of that ) to hinder the adoption of systemd in the project. Dont hesitate to be in contact if you need help with that since these kind of migration/integration work in distributions with systemd is beneficial to *all* so it does not take many resources from systemd community from every distro to lend a hand and help with that migration. It just requires a bit of organizing and packagers ( in all distros ) to be on stand by when that happens and it will be quickly over. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
