No, because you would have already fixed the/etc/init.d/zfs file
If you can fix it in/etc/init.d/zfs, you can just as easily copy/usr/lib/systemd/system/zfs.service to/etc/systemd/system and fix/etc/systemd/system/zfs.service
instead of googling "systemd dependancies editor"
Surely you have vi or emacs or nano or pico or something available, with which to add a Requires entry (see systemd.unit(5)) to the zfs service unit?
Maybe mr smug, you can tell me where on earth the ACPI events from the sleep key are going and why SystemD refuses to pass them on anywhere sensible.
The sleep button works perfectly here on a system running systemd and KDE. Maybe you have a problem somewhere else.
Because I can't debug problems when they arise easily. That makes it pretty inferior to me.
The only seemingly valid complaint I have seen is that systemctl doesn't provide the exist process. But, this is only the case for Type=simple (yes, the default type), where you probably want Type=forking or Type=oneshot.
Not having access to the exit status or syslog messages makes life difficult.
1)Don't omit Type=, or use Type=simple, in the case of a non-simple process, you probably want Type=forking 2)Surely you're learned how to use 'systemctl status foo' or journalctl ?
I've had to to train all of my junior admins on how to use strace. That took me quite a bit of time, and it takes them a lot of time to go through the huge log files that creates just to find the error string that systemd swallowed. I don't dispute that systemd is better when you have complex dependencies, but it sucks when a unit won't start and it gives you no clue as to why.
You may have been better off reading systemd.service(5), but junior admins should be taught how to use strace regardless...
I think part of the problem is that sysvinit is basically feature-less, and for a running system actually does nothing (it is initscripts that does this), and so people are used to just having the entire system run by scripts with no useful features (e.g.doing something different with stderr than leaving it to the controlling terminal, letting the current user pollute the environment and thus never have consistent starting of services etc. etc.).
If you had correctly used Type=oneshot, you wouldn't have been in the dark and would have seen this on the terminal:
# systemctl start broken_systemd Job for broken_systemd.service failed. See 'systemctl status broken_systemd.service' and 'journalctl -xn' for details. # systemctl status broken_systemd -l broken_systemd.service - Broken systemd example
Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
Active: failed (Result: exit-code) since Sat 2015-04-25 07:53:07 SAST; 26s ago
Process: 7880 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
Main PID: 7880 (code=exited, status=1/FAILURE)
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Example systemd service Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Error that should not be thrown away Apr 25 07:53:07 HOST systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE Apr 25 07:53:07 HOST systemd[1]: Failed to start Broken systemd example. Apr 25 07:53:07 HOST systemd[1]: Unit broken_systemd.service entered failed state.
Just because sysvinit couldn't do anything useful with stderr from a one-short service (and leave it to the controlling terminal to do something with it) doesn't mean systemd shouldn't. Logging it, and informing the user that the job didn't start and where to see more information is much more useful.
And why is it that the woman is the one to take care of children?
I don't know if you have noticed that men and women are different. Women happen to be more suitable for taking care of babies because they can do one thing men can't: breastfeed.
At least, that is one of the reasons why my wife took 6 months maternity leave, and luckily in those 6 months our situation changed so that we could manage without her working. And we have had more children since, so she is still at home.
Of course, we do realise that she will have fewer years of work experience when/if she returns to work, and this also not earn what she would have if she had continued working. However, the investment in our kids/family life is worth it.
Really? Please link to mailing list posts from Lennart pushing Debian or Ubuntu to to adopt systemd (advising on features/benefits relevant to an upcoming decison the distro already had to make does not count).
Note that sysv init only does anything useful for 3 use cases: -booting the system -shutting down the system -changing run levels (which both of tje above are considered to be)
On most machines these days, no one changes run levels more than once or twice a month.
Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.
Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.
On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the/proc/$pid/environ of a service started at boot to one that has been restarted since...
systemd is noy perfect, but it is much better in all of these aspects.
So sysv init (or bsd init) isn't good enough for your desktop, why is it (or in actual fact, upstart in sysv compat mode) good enough for servers (where some of its features are more useful). Or do you want to duplicate configuration or functionality by running an 'init' system which basically has no useful features during the majority of time it is running and a supervising system (which doesn't integrate at all with supplied diatro packages)?
Do you really like the fact that all distros require separate scripts (e.g. some that use/etc/rc.d/functions for RH-derived distros, other scripts that work on Debian-derived distros, others for SUSE, Arch etc., because sysv init basically has no useful features and all distros implemented the missing minimumfunctionality differently?
The last two need to run at least 2 and 4 VMs with 3Gb ram each respectively. Running chrome for day-to-day work would make these setups impractical, whereas firefox runs well (firefox needs to be restarted more frequently than the OSs, but not significantly).
Additionally, chrome/chromium have some display issues on one machine (linux, KDE, radeon).
No, I can't (or can't justify just for chrome when firefox is fine) adding more ram, most of the above are work machines, 1 already is fully populated with DDR2, upgrading the ram would be prohibitively expensive
Have you tried Red Hat Enterprise Virtualisation ( http://www.redhat.com/promo/rh... )? It adds the management features like vCenter Server adds the vSphere to ESXi, and costs less for a suppprted environment than the cheapest VMWare option, and has feature parity and performs better (kvm).
The introduction of systemd has unilaterally created a polarization of the GNU/Linux community
Citation needed. It seems to me the polarization has been created in the Debian community by the anti-systemd crowd. Instead of fixing the problems that resulted in systemd acquiring more of the Linux user-space functionality, or work actively towards supporting multiple init systems, they continually claim that there are divisions in the community created by the systemd developers.
This doesn't seem to be an issue in other distributions.
It shows that the kids running systemd don't get the concepts of stderr or exit statuses.
No, this example shows that in previous 'init systems', the init system was adding no value after the default runlevel was reached. You were basically just running a script, and you had the option to check its return value. It just so happens that the init system would also run this script when changing to the relevant run level (but not in exactly the same way).
In systemd, systemctl tells systemd to start the service. systemctl doesn't exec the script in question itself.
The difference is that, under e.g. sysvinit, while a server remains at a specific runlevel, init scripts are no different than any other scripts. This also means that there are potential problems, where the last person to have started the service may have had different environment variables which made the service work (PATH, LANG, LC_ALL, JAVA_HOME etc. etc.), now when it fails (or the machine is rebooted), you (or init, in the one case it actually does something) try and start it, and it doesn't behave the same way. Go compare the/proc/$pid/environ for a service on a sysvinit box that was started at boot to the environ if you restart it later. In systemd, since systemctl isn't forking the init script (or similar), a clean environment can be gauranteed.
So, since systemctl isn't exec()ing the script, systemctl doesn't have to wait for the execution to finish before it returns.
Setting Type=forking will change the behaviour to what you expect. Why? In the case of a forking daemon, the init system *should* wait for the process to fork before it returns. Maybe there should be another option for Type that doesn't require a PID file but does return the exit status.
However, instead you can always call sytemctl is-active broken_systemd after-the-fact. But, if your 'service' may take some time to get through it's initial checking, maybe you are better off using Type=forking.
systemctl status postfix # will show the last 10 log entries for the service, along with all the other useful information journalctl -f # tail all logs journalctl -b/usr/lib64/postfix/pickup # show just the logs for this boot of the postfix pickup binary
These are a few examples from a different distro, so you'll have to use totally different commands and log file names... oh wait, with systemd you don't need to do that, you can always easily find the logs unlike before where each distro configured it's chosen default logging daemon differently by default.
It looks like you haven't even bothered to read anything about systemd, and it's not like you have an excuse: $ rpm -qd systemd|grep man|wc -l 291
Example, libvirt doesn't use/etc/network/interfaces, this is stupid and complicates firewalling scripts and so on.
/etc/network/interfaces is Debian-specific. Libvirt (optionally) supports the netcf library, which is a cross-platform network configuration library that claims to support Debian. Is libvirt in Debian compiled against netcf?
And it insists on running its own copies of dnsmasq, rather than just dropping some files in/etc/dnsmasq.d. What a PITA. Use the goddamned operating system, that's what it's there for.
So because Debian has bugs in their 'upgrade-to-syatemd' process in their in-development release, which numerous other Linux distros (Red Hat/Fedora, SUSE, Arch, Mageia) *don't* have in their released versions, your reaction is to ditch your distro?
Slashdot Mirror
Really?
I found the systemd documentation installed on my machines tgst have systemd to be very comprehensive.
But it seems the anti-systemd crowd don't know how to find or read man pages, so I'll provide a link to one they can read: here .
You obviously aren't aware of inetd or xinetd, although you probably have them running, started by your precious sysvinit.
No, because you would have already fixed the /etc/init.d/zfs file
If you can fix it in /etc/init.d/zfs, you can just as easily copy /usr/lib/systemd/system/zfs.service to /etc/systemd/system and fix /etc/systemd/system/zfs.service
instead of googling "systemd dependancies editor"
Surely you have vi or emacs or nano or pico or something available, with which to add a Requires entry (see systemd.unit(5)) to the zfs service unit?
Maybe mr smug, you can tell me where on earth the ACPI events from the sleep key are going and why SystemD refuses to pass them on anywhere sensible.
The sleep button works perfectly here on a system running systemd and KDE. Maybe you have a problem somewhere else.
Because I can't debug problems when they arise easily. That makes it pretty inferior to me.
The only seemingly valid complaint I have seen is that systemctl doesn't provide the exist process. But, this is only the case for Type=simple (yes, the default type), where you probably want Type=forking or Type=oneshot.
Not having access to the exit status or syslog messages makes life difficult.
1)Don't omit Type=, or use Type=simple, in the case of a non-simple process, you probably want Type=forking
2)Surely you're learned how to use 'systemctl status foo' or journalctl ?
I've had to to train all of my junior admins on how to use strace. That took me quite a bit of time, and it takes them a lot of time to go through the huge log files that creates just to find the error string that systemd swallowed. I don't dispute that systemd is better when you have complex dependencies, but it sucks when a unit won't start and it gives you no clue as to why.
You may have been better off reading systemd.service(5), but junior admins should be taught how to use strace regardless ...
I think part of the problem is that sysvinit is basically feature-less, and for a running system actually does nothing (it is initscripts that does this), and so people are used to just having the entire system run by scripts with no useful features (e.g.doing something different with stderr than leaving it to the controlling terminal, letting the current user pollute the environment and thus never have consistent starting of services etc. etc.).
If you had correctly used Type=oneshot, you wouldn't have been in the dark and would have seen this on the terminal:
# systemctl start broken_systemd
Job for broken_systemd.service failed. See 'systemctl status broken_systemd.service' and 'journalctl -xn' for details.
# systemctl status broken_systemd -l
broken_systemd.service - Broken systemd example
Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
Active: failed (Result: exit-code) since Sat 2015-04-25 07:53:07 SAST; 26s ago
Process: 7880 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
Main PID: 7880 (code=exited, status=1/FAILURE)
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Example systemd service
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Error that should not be thrown away
Apr 25 07:53:07 HOST systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 25 07:53:07 HOST systemd[1]: Failed to start Broken systemd example.
Apr 25 07:53:07 HOST systemd[1]: Unit broken_systemd.service entered failed state.
Just because sysvinit couldn't do anything useful with stderr from a one-short service (and leave it to the controlling terminal to do something with it) doesn't mean systemd shouldn't. Logging it, and informing the user that the job didn't start and where to see more information is much more useful.
And why is it that the woman is the one to take care of children?
I don't know if you have noticed that men and women are different. Women happen to be more suitable for taking care of babies because they can do one thing men can't: breastfeed.
At least, that is one of the reasons why my wife took 6 months maternity leave, and luckily in those 6 months our situation changed so that we could manage without her working. And we have had more children since, so she is still at home.
Of course, we do realise that she will have fewer years of work experience when/if she returns to work, and this also not earn what she would have if she had continued working. However, the investment in our kids/family life is worth it.
Isn't there a --no-remote or similar option?
Or you could install and use links.
Or you could setup apache or similar to serve the documentation.
Really? Please link to mailing list posts from Lennart pushing Debian or Ubuntu to to adopt systemd (advising on features/benefits relevant to an upcoming decison the distro already had to make does not count).
systemd can run legacy sysv init scripts just as badly (or better than) as sysv init can. No need for alarm or panic.
But, why do that when a 4-line config file can do most of what you need.
In the case of a more complex service, you can write a pre-exec script, so that may require some conversion.
Note that sysv init only does anything useful for 3 use cases:
-booting the system
-shutting down the system
-changing run levels (which both of tje above are considered to be)
On most machines these days, no one changes run levels more than once or twice a month.
Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.
Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.
On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the /proc/$pid/environ of a service started at boot to one that has been restarted since ...
systemd is noy perfect, but it is much better in all of these aspects.
So sysv init (or bsd init) isn't good enough for your desktop, why is it (or in actual fact, upstart in sysv compat mode) good enough for servers (where some of its features are more useful). Or do you want to duplicate configuration or functionality by running an 'init' system which basically has no useful features during the majority of time it is running and a supervising system (which doesn't integrate at all with supplied diatro packages)?
Do you really like the fact that all distros require separate scripts (e.g. some that use /etc/rc.d/functions for RH-derived distros, other scripts that work on Debian-derived distros, others for SUSE, Arch etc., because sysv init basically has no useful features and all distros implemented the missing minimumfunctionality differently?
The machines I regularly use have:
4GB
8GB
16GB
The last two need to run at least 2 and 4 VMs with 3Gb ram each respectively. Running chrome for day-to-day work would make these setups impractical, whereas firefox runs well (firefox needs to be restarted more frequently than the OSs, but not significantly).
Additionally, chrome/chromium have some display issues on one machine (linux, KDE, radeon).
No, I can't (or can't justify just for chrome when firefox is fine) adding more ram, most of the above are work machines, 1 already is fully populated with DDR2, upgrading the ram would be prohibitively expensive
Have you tried Red Hat Enterprise Virtualisation ( http://www.redhat.com/promo/rh... )? It adds the management features like vCenter Server adds the vSphere to ESXi, and costs less for a suppprted environment than the cheapest VMWare option, and has feature parity and performs better (kvm).
The introduction of systemd has unilaterally created a polarization of the GNU/Linux community
Citation needed. It seems to me the polarization has been created in the Debian community by the anti-systemd crowd. Instead of fixing the problems that resulted in systemd acquiring more of the Linux user-space functionality, or work actively towards supporting multiple init systems, they continually claim that there are divisions in the community created by the systemd developers.
This doesn't seem to be an issue in other distributions.
It shows that the kids running systemd don't get the concepts of stderr or exit statuses.
No, this example shows that in previous 'init systems', the init system was adding no value after the default runlevel was reached. You were basically just running a script, and you had the option to check its return value. It just so happens that the init system would also run this script when changing to the relevant run level (but not in exactly the same way).
In systemd, systemctl tells systemd to start the service. systemctl doesn't exec the script in question itself.
The difference is that, under e.g. sysvinit, while a server remains at a specific runlevel, init scripts are no different than any other scripts. This also means that there are potential problems, where the last person to have started the service may have had different environment variables which made the service work (PATH, LANG, LC_ALL, JAVA_HOME etc. etc.), now when it fails (or the machine is rebooted), you (or init, in the one case it actually does something) try and start it, and it doesn't behave the same way. Go compare the /proc/$pid/environ for a service on a sysvinit box that was started at boot to the environ if you restart it later. In systemd, since systemctl isn't forking the init script (or similar), a clean environment can be gauranteed.
So, since systemctl isn't exec()ing the script, systemctl doesn't have to wait for the execution to finish before it returns.
Setting Type=forking will change the behaviour to what you expect. Why? In the case of a forking daemon, the init system *should* wait for the process to fork before it returns. Maybe there should be another option for Type that doesn't require a PID file but does return the exit status.
However, instead you can always call sytemctl is-active broken_systemd after-the-fact. But, if your 'service' may take some time to get through it's initial checking, maybe you are better off using Type=forking.
Really? I find it easier to troubleshoot, as you can easily find the logs for any service (e.g. foo):
systemctl status foo
systemctl status postfix # will show the last 10 log entries for the service, along with all the other useful information /usr/lib64/postfix/pickup # show just the logs for this boot of the postfix pickup binary
journalctl -f # tail all logs
journalctl -b
These are a few examples from a different distro, so you'll have to use totally different commands and log file names ... oh wait, with systemd you don't need to do that, you can always easily find the logs unlike before where each distro configured it's chosen default logging daemon differently by default.
It looks like you haven't even bothered to read anything about systemd, and it's not like you have an excuse:
$ rpm -qd systemd|grep man|wc -l
291
A good place to start is probably 'man systemd'
My systemd experience this morning was a total lockout and lockup while booting forcing a full re-install of my Red Hat Linux.
If it *really* was that bad, surely you could have booted into a rescue environment?
I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7
Did you even try it?
What bugs did you encounter that were specifically due to systemd? Did you file any?
We are preparing to start rolling out RHEL7 (still have some internal packages to rebuild), and systemd didn't really feature as a problem at all.
Systemd has been the most divisive force in the Linux community lately, and perhaps ever.
s/Linux/Debian/
Many other distros switched to systemd with no antics, commotion, and very few problems.
Maybe the problem here is Debian, not systemd?
Example, libvirt doesn't use /etc/network/interfaces, this is stupid and complicates firewalling scripts and so on.
/etc/network/interfaces is Debian-specific. Libvirt (optionally) supports the netcf library, which is a cross-platform network configuration library that claims to support Debian. Is libvirt in Debian compiled against netcf?
And it insists on running its own copies of dnsmasq, rather than just dropping some files in /etc/dnsmasq.d. What a PITA. Use the goddamned operating system, that's what it's there for.
Have you filed a bug?
So because Debian has bugs in their 'upgrade-to-syatemd' process in their in-development release, which numerous other Linux distros (Red Hat/Fedora, SUSE, Arch, Mageia) *don't* have in their released versions, your reaction is to ditch your distro?
Wow.
Maybe you shouldn't have been running testing ...
So, you don't have kids.