Re: sl7 systemd sysvinit
Hi Steven Haigh! On 2014.08.26 at 09:57:22 +1000, Steven Haigh wrote next: - simple and predictable service files Like my case of networking randomly failing to start. No debugging or errors logged, and no way of predicting a failure. Err, where did you find system where systemd initializes network? I think in all current distros something else (like NetworkManager) does it, which is significantly more annoying to debug compared to old network scripts, but systemd has nothing to do with it at all. systemd network initialization is/will be available for containers, and it won't appear in EL7 for host system for a long time - maybe at all. I won't deny that switching to systemd might require some tweaking because it all starts too fast and some services might fail to init because they are started before network does, but this is to be expected from parallel boot and is fixed by either enabling networkmanager wait online service, by tweaking boot dependencies or by other options, like x-systemd.automount in fstab for your nfs shares. - ability to wrap a random application into service with just a few lines of config Yes and no. When you really start using systemd, you learn quickly how to create service files - because you end up writing a lot of them because basic options are missing. If your app doesn't utilise a config Learning new things is expected from SA managing these things. Also, bash scripts for more options are still there, only now you can put there few lines of actual, meaningful startup code and let systemd call this small script from service file for certain action. - no more extra-complicated init scripts using various hacks and magic for non-C applications (if you ever tried to wrap some random python or java application into service, you'll know what I'm talking about right away) By complicated you mean working? I start several python daemons on boot with initscripts - and it is very simple - almost trivial. Compare to the guesswork of trying to find out why a service failed to start. Starting is easy, stopping and getting status is hard. Especially with complications like no pidfile from application, it forks or it's launched under script which automatically restarts it. And especially when a (typical large) service takes many seconds or even minutes to shutdown and you need to *actually* make sure it shutdowns by letting it shutdown gracefully for, say, a minute, then kill it with -9. - automatic restart of services This is not always desirable. It's an option in service file. - thanks to these features (service created with few lines of code, automatic restart, some others) - no more need for runit, daemontools or supervisord , you can have all the benefits of these systems while having only one flat init system (systemd) for both system and your services - reliable pid tracking, which even follows the forks - that's something not current init system or others like runit are able to do. No more hassle with complex pgrep's for applications that didn't leave pidfile behind (again, applications that rename or fork themselves and non-C applications can be extremely annoying here). But systemd has reliable way of knowing all the pids that each service has created without any hacks at all - thanks to cgroups support. None of which really works out of the box without you writing your own service file. We have used /var/run for PID files for decades - saying it isn't reliable is ignorance? 3 lines for service file vs complicated pid file searching, what wins? pid /var/run requires LOTS of extra work when you're dealing with lots of random applications which have to work as services. No one bothers / has time to write and control pidfile from application (including correct tracking of stale files, tracking that stale file doesn't belong to different process and such has to be done in script anyway). Application might not have rights to write pidfile, after all - say, you need to run bunch of applications without root rights - it means you must wrap them into package and package /var/run/myapp with correct privileges, then change config/option of each application to write pidfile to /var/run/myapp instead of /var/run and so on. You might call these small things, but what you eventually end with is a very-very long and complicated mega init script for python services and similar mega script for java services, which uses LOTS of bash code to work around all these problems in init, including stale pidfiles and long shutdown times. And try to change as little config lines on top as possible to accommodate to your needs with new scripts. Welcome to systemd: it's possible to throw out these mega intellectual init scripts and just use these few lines in service file. pid tracking with cgroups is very reliable and no amount of hacks and strange behaviour can confuse it, also doesn't require root privileges to write a
Re: sl7 systemd sysvinit
On 26/08/14 01:57, Steven Haigh wrote: On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote: Hi Ken Teh! On 2014.08.25 at 12:58:21 -0500, Ken Teh wrote next: I read the following article on systemd http://ifwnewsletters.newsletters.infoworld.com/t/9625863/474699771/826094/14/ The comments suggested one could still revert to sysvinit. Is this just wishful thinking on my part? Yes. As an exercise, why don't you revert EL6's upstart to sysvinit? Note that enabling/disabling some services on EL6 *requires* you to use upstart-specific initctl, you simply won't notice these services if you will only look at chkconfig. systemd offers many benefits for system administrators, like: No, no it doesn't. [...snipped out ranting...] First of all, systemd is a new way of thinking bootup and system management. It requires users to adjust to the a way of doing things. I used to be a sharp systemd critic, after struggling with it during testing of Fedora 15. I've run Fedora 19 and Fedora 20, and accepted that systemd is not going away. And I do begin to like it. And I very much look forward to it in EL7. Even my Jolla phone uses systemd, and it was a breeze to write the needed unit file to make it load my own firewall rules at boot. Remember that systemd replaces _more_ than just the init scripts and the boot process. It is a full blown system _manager_. Its task is to ensure a predictable behaviour as long as the system runs. If you plug in or remove hardware, the appropriate actions should happen. If a specific network becomes available, network filesystems can automatically be mounted. Restarting of processes which dies can be tackled automatically (and disabled where you don't want it). Resource management via cgroups can be tackled in a more consistent way. And more. All this via a more standardised set of tools, which knows about each other and tries to avoid to trip on each others toes. I can agree that systemd has a broad footprint. But the more I play with it, the more I can understand why it needs to have a broader scope than just kicking off init scripts at boot. So for debugging ... you'll get some nice clues here: http://freedesktop.org/wiki/Software/systemd/Debugging/ More on verifying bootups: http://0pointer.de/blog/projects/systemd-for-admins-1.html More on the journal: http://0pointer.de/blog/projects/journalctl.html Making unit files from sys-v init scripts: http://0pointer.de/blog/projects/systemd-for-admins-3.html In fact, there's a lot of good information from the systemd site: http://freedesktop.org/wiki/Software/systemd/ Moving towards a more modern system management is painful when you're used to the good ol'tools. Systemd is tearing up a lot of old stuff which I begin to see should have been improved ages ago. Canonical dared doing a lot with upstart. And systemd just takes a bigger leap. A lot can also be said about that the old sys-v approach has worked well for so long that it can't be wrong. But I'd say that if you take the best racing driver from the 60s and put him into a racing car of this century, he probably won't win a race. Because the technology has evolved. We need tools and drivers of the new technology to be in sync. So I encourage people to give systemd a fair chance. Accept that it does things differently, and see how it can be used to reach your goals. Hopefully you'll see what I've seen so far, that it actually works quite well. -- kind regards, David Sommerseth
Re: sl7 systemd sysvinit
On 26/08/2014 9:42 PM, David Sommerseth wrote: On 26/08/14 01:57, Steven Haigh wrote: On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote: Hi Ken Teh! On 2014.08.25 at 12:58:21 -0500, Ken Teh wrote next: I read the following article on systemd http://ifwnewsletters.newsletters.infoworld.com/t/9625863/474699771/826094/14/ The comments suggested one could still revert to sysvinit. Is this just wishful thinking on my part? Yes. As an exercise, why don't you revert EL6's upstart to sysvinit? Note that enabling/disabling some services on EL6 *requires* you to use upstart-specific initctl, you simply won't notice these services if you will only look at chkconfig. systemd offers many benefits for system administrators, like: No, no it doesn't. [...snipped out ranting...] Today I learnt that if you don't fit a standard model for usage, you become a ranter First of all, systemd is a new way of thinking bootup and system management. It requires users to adjust to the a way of doing things. I used to be a sharp systemd critic, after struggling with it during testing of Fedora 15. I've run Fedora 19 and Fedora 20, and accepted that systemd is not going away. And I do begin to like it. And I very much look forward to it in EL7. Even my Jolla phone uses systemd, and it was a breeze to write the needed unit file to make it load my own firewall rules at boot. Remember that systemd replaces _more_ than just the init scripts and the boot process. It is a full blown system _manager_. Its task is to ensure a predictable behaviour as long as the system runs. If you plug in or remove hardware, the appropriate actions should happen. If a specific network becomes available, network filesystems can automatically be mounted. Restarting of processes which dies can be tackled automatically (and disabled where you don't want it). Resource management via cgroups can be tackled in a more consistent way. And more. All this via a more standardised set of tools, which knows about each other and tries to avoid to trip on each others toes. I can agree that systemd has a broad footprint. But the more I play with it, the more I can understand why it needs to have a broader scope than just kicking off init scripts at boot. snip So I encourage people to give systemd a fair chance. Accept that it does things differently, and see how it can be used to reach your goals. Hopefully you'll see what I've seen so far, that it actually works quite well. I've given it a fair go - but there is a BIG problem if you don't fit the standard model that systemd forces you into. Ok, so off the top of my head, the following is broken with systemd as of right now: 1) Logwatch doesn't work at all with journals. 2) You can't pipe the journal to a different machine as per remote syslogging (which is a standard for decades). You can run syslog *as well* as systemd logging, but output is limited compared to journals. 3) SNMP monitors that monitor log files are broken because of point #2. 4) A heap of very basic changes require you to write your own service file for systemd. While it isn't hard, I found that roughly half of services I required to run needed me to write my own service file (remember, you can't just edit the one in /usr/./ etc). 5) Network stability was faulty in my tests - you could not guarantee that networking would start (this is a static IP case) on every boot. This alone is critical. 6) The concept of a binary log file is flawed from the start. IBM used to do it, but afaik, abandoned the idea in most products. 7) Parallel service start introduces a range of issues that do not happen in serial boot order. In enterprise land, we care about stability - not speed. As a comparison, the BIOS on the RAID card takes longer (usually 45-50 seconds) than booting the system no matter what OS / init system. 8) SystemD isn't just about system boot. It replaces logging, cron, monitoring, service init and more. It gets its claws into everything - but not everything it replaces gets done well. I'm half expecting it to grow an email client in there as well. I have no problems with change when it is done well. The problem is, SystemD has not been done well and introduces more problems than it fixes. To say that it is perfect more indicates that you fit the SystemD mold rather than SystemD actually doing its job properly. In other news, there was a recent slashdot article on this exact subject: http://linux.slashdot.org/story/14/08/25/1730245/choose-your-side-on-the-linux-divide There is certainly a new trend of linux developers around - and the problems that are being introduced now are the same ones that were fixed decades ago by the previous generation of developers. The problems haven't changed - only the way they are approached. -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299
Re: sl7 systemd sysvinit
On Mon, Aug 25, 2014 at 7:57 PM, Steven Haigh net...@crc.id.au wrote: On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote: - simple and predictable service files Like my case of networking randomly failing to start. No debugging or errors logged, and no way of predicting a failure. For debugging: systemctl status network.service systemctl status NetworkManager.service For failures: I haven't any networking problems and the guys testing RHEL7 at my $dayjob haven't reported any such problems. - ability to wrap a random application into service with just a few lines of config Yes and no. When you really start using systemd, you learn quickly how to create service files - because you end up writing a lot of them because basic options are missing. If your app doesn't utilise a config file, then you can bet you'll be copying across the default systemd service file and modifying it to suit your needs. There is no other way. You can/should use a snippet such as /etc/systemd/system/daemon.service.d/*.conf which consist of, for example, EnvironmentFile=-/etc/sysconfig/daemon - no more extra-complicated init scripts using various hacks and magic for non-C applications (if you ever tried to wrap some random python or java application into service, you'll know what I'm talking about right away) By complicated you mean working? I start several python daemons on boot with initscripts - and it is very simple - almost trivial. Compare to the guesswork of trying to find out why a service failed to start. systemctl status daemon.service ?! Plans are afoot to have systemd replace ntpd and the idea to replace the kernel consoles with userspace systemd foo. Lets also ignore the binary log formats which kills long time monitoring tools (logwatch etc) and systemd really is a solution hunting for a problem. journald forwards its logs to rsyslog by default so logwatch and co shouldn't have any problems.
FASTBUGS for SL 6x i386, x86_64 now available
The following FASTBUGS have been uploaded to http://ftp.scientificlinux.org/linux/scientific/6x/i386/updates/fastbugs/ http://ftp.scientificlinux.org/linux/scientific/6x/x86_64/updates/fastbugs/ i386: ccid-1.3.9-6.1.el6_5.i686.rpm glibc-2.12-1.132.el6_5.3.i686.rpm glibc-common-2.12-1.132.el6_5.3.i686.rpm glibc-devel-2.12-1.132.el6_5.3.i686.rpm glibc-headers-2.12-1.132.el6_5.3.i686.rpm glibc-static-2.12-1.132.el6_5.3.i686.rpm glibc-utils-2.12-1.132.el6_5.3.i686.rpm hwloc-1.5-2.el6_5.i686.rpm hwloc-devel-1.5-2.el6_5.i686.rpm nscd-2.12-1.132.el6_5.3.i686.rpm x86_64: ccid-1.3.9-6.1.el6_5.x86_64.rpm glibc-2.12-1.132.el6_5.3.i686.rpm glibc-2.12-1.132.el6_5.3.x86_64.rpm glibc-common-2.12-1.132.el6_5.3.x86_64.rpm glibc-devel-2.12-1.132.el6_5.3.i686.rpm glibc-devel-2.12-1.132.el6_5.3.x86_64.rpm glibc-headers-2.12-1.132.el6_5.3.x86_64.rpm glibc-static-2.12-1.132.el6_5.3.i686.rpm glibc-static-2.12-1.132.el6_5.3.x86_64.rpm glibc-utils-2.12-1.132.el6_5.3.x86_64.rpm hwloc-1.5-2.el6_5.i686.rpm hwloc-1.5-2.el6_5.x86_64.rpm hwloc-devel-1.5-2.el6_5.i686.rpm hwloc-devel-1.5-2.el6_5.x86_64.rpm nscd-2.12-1.132.el6_5.3.x86_64.rpm
