Re: [systemd-devel] timed events
On Fri, 29.06.12 10:49, Nathan (qwerty@gmail.com) wrote: Hello, I have built systemd version 26 for red hat enterprise 6.2. It works well. I am trying to replace a half broken init system/service management system we have running which was built in-house (and all the developers have left) I am even managing some daemons of my own with it successfully. Looking at the systemd.timer documentation it seems as though all the timers are relative. Is there any way to get absolute timers relative to real time (cron like functionality - even in a later version?). As Auke mentioned: yes currently they are all relative only, and that still includes the newest version. We definitely want to add calendar time support as well, but are a bit afraid of picking the right language for expressing time events. i.e. whether we should just try to reuse the cron syntax, come up with something new, or try to focus on the iCal or ISO syntaxes. The actual implementation shouldn't be too hard and with today's kernel capabilities would allow for a lot of addtional interesting features (like really easy support for having timer events that wake up the machine from suspend and things likt that) Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). No this isn't really supported nicely. Finally are there acls (or similar) so that user X can manage the state of his services and only his services? You can use D-Bus policy for this, but it has quite an awful syntax. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
2012/6/29 David Strauss da...@davidstrauss.net: snip suggestions Having a timer-based service start/stop bgpd.service works fine. I just wanted to offer a dependency-based take. Thanks. Both suggestions are strictly better than the paper note based solution, and your reply does prove that nothing needs to be changed in systemd to get the effect I want. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
On Fri, Jun 29, 2012 at 4:31 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Looking at the systemd.timer documentation it seems as though all the timers are relative. Is there any way to get absolute timers relative to real time (cron like functionality - even in a later version?). not currently, the timer could should be expanded but it's not that simple to write something like that consistently. We do not have calendar time event at the moment, because at the time we did all that, we missed the needed kernel pieces. Note, that cron needs to wake up every minute and checks if someone has changed the wall clock, and we did not want to do that. The proper kernel interfaces are there now for timerfd, and a cron-like functionality can be implemented in systemd: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99ee5315dac6211e972fa3f23bcc9a0343ff58c4 One piece that needs to be sorted out on the systemd side is the notation how to specify the format for specific calendar events, and for re-occuring events, and how and where to store when the last execution happened, to allow cron + anachron + at functionality in one and the same consistent interface. It *may* be some subset or something inspired from rfc2445, but I don't think anybody has really looked into it so far. The current (not really thought out) idea is for systemd to support all the simple cron.daily, cron.weekly, ... things and support that with built-in timers, but leave *all* custom cron jobs and user-cron to the original cron implementation. Which means, that most of the usual systems will not need to install cron/at, but have all the periodic cleanup tasks still hooked up and functional by default. If cron is installed, the service file would check for the existence of a custom cron config file and would start cron only if it needs to run. I short: if you need cron run cron, but if you need only the usual periodic tasks, or just calendar events and don't care about cron configuration files, systemd should do it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
2012/6/29 Kok, Auke-jan H auke-jan.h@intel.com: On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). cheap trick: make a script and run it from a timer, have the script run `systemctl ...` better trick: fix the daemon to do all of this properly. Hello. The company I work for has a similar need. The director has permitted me to disclose the details in full, in hope that this will permit you to understand the use case better and understand why fix the daemon is not a possible solution in our case. We are not using systemd yet on our servers, but this doesn't make the problem statement invalid. We have several servers hosted at different ISPs, and our own autonomous system. The service is provided to our clients via IPv4 anycast. So, at each of the servers, we run bgpd (from quagga) and announce a route to our own IPv4 block. This means that each client will be routed to the nearest (in the BGP sense) server. It also protects our service against outages that affect the entire ISP, and allows us to perform maintenance and software upgrades safely (i.e. with near zero visible downtime for clients) by stopping bgpd first. The issue is that twice in the company's lifetime there was a payment problem with one of the servers. When this happened, the ISP did not shut down the affected server. Instead, they somehow firewalled the packets destined to it, but the BGP session was left intact. End result: the route is still announced into the global routing table, but doesn't work, and some clients see service interruption. So, as a protection against such mistakes, we need some form of a custom dead man's switch that would stop bgpd if none of the test IPv4 addresses is pingable. Of course, such monitoring need is specific to our use case, and other companies will either not need it at all or write a dead man's switch with a different logic. So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. The run systemctl from timer is close, but not close enough: extra care is needed during maintenance periods to disable the dead man's switch script (so it doesn't restart bgpd contrary to the administrator's decision) and not to forget to reenable it later. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
On Thu, Jun 28, 2012 at 11:01 PM, Alexander E. Patrakov patra...@gmail.com wrote: 2012/6/29 Kok, Auke-jan H auke-jan.h@intel.com: On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). cheap trick: make a script and run it from a timer, have the script run `systemctl ...` better trick: fix the daemon to do all of this properly. Hello. The company I work for has a similar need. The director has permitted me to disclose the details in full, in hope that this will permit you to understand the use case better and understand why fix the daemon is not a possible solution in our case. We are not using systemd yet on our servers, but this doesn't make the problem statement invalid. We have several servers hosted at different ISPs, and our own autonomous system. The service is provided to our clients via IPv4 anycast. So, at each of the servers, we run bgpd (from quagga) and announce a route to our own IPv4 block. This means that each client will be routed to the nearest (in the BGP sense) server. It also protects our service against outages that affect the entire ISP, and allows us to perform maintenance and software upgrades safely (i.e. with near zero visible downtime for clients) by stopping bgpd first. The issue is that twice in the company's lifetime there was a payment problem with one of the servers. When this happened, the ISP did not shut down the affected server. Instead, they somehow firewalled the packets destined to it, but the BGP session was left intact. End result: the route is still announced into the global routing table, but doesn't work, and some clients see service interruption. So, as a protection against such mistakes, we need some form of a custom dead man's switch that would stop bgpd if none of the test IPv4 addresses is pingable. Of course, such monitoring need is specific to our use case, and other companies will either not need it at all or write a dead man's switch with a different logic. So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. The run systemctl from timer is close, but not close enough: extra care is needed during maintenance periods to disable the dead man's switch script (so it doesn't restart bgpd contrary to the administrator's decision) and not to forget to reenable it later. nothing a sticky note on a monitor couldn't fix. A real solution would be to use some sort of heartbeat feature, or just wrap the bgpd in a wrapper program that takes care of starting/stopping it. That allows you to keep the wrapper running from systemd at all times. No timers needed. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
On Thu, Jun 28, 2012 at 11:01 PM, Alexander E. Patrakov patra...@gmail.com wrote: So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. You could also have a dead-mans-switch.service that declares bgpd.service's dependency on it. If dead-mans-switch.service fails, bgpd.service will get shut down. As long as dead-mans-switch.service exits with a non-zero code, it will even get marked as failed, which is probably a boon in your use case. Restarting bgpd.service would be manual after dead-mans-switch.service failure. If you *did* want bgpd.service to restart when the connection gets re-enabled, dead-mans-switch.service can depend on bgpd.service with bgpd.service configured to run only when required by dependencies. dead-mans-switch.service can exit with code 1 on failure, and systemd can attempt to revive dead-mans-switch.service on a configurable schedule (say, every 10 minutes) in the unit. Having a timer-based service start/stop bgpd.service works fine. I just wanted to offer a dependency-based take. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Hello, I have built systemd version 26 for red hat enterprise 6.2. It works well. I am trying to replace a half broken init system/service management system we have running which was built in-house (and all the developers have left) I am even managing some daemons of my own with it successfully. Looking at the systemd.timer documentation it seems as though all the timers are relative. Is there any way to get absolute timers relative to real time (cron like functionality - even in a later version?). not currently, the timer could should be expanded but it's not that simple to write something like that consistently. Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). cheap trick: make a script and run it from a timer, have the script run `systemctl ...` better trick: fix the daemon to do all of this properly. Finally are there acls (or similar) so that user X can manage the state of his services and only his services? yes, with systemd --user, you can run separate instances for different UID's that can only be managed by each UID individually. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
