Well, Ben did point out the little problem of Jessie being frozen, you need a bloody good reason to unfreeze at this juncture, and is Chromium important enough?
Not that I was going to use a system that kowtows to RMS by calling itself GNU/Linux anyway, but the OS is there to support the software I use, and I use Chrome on Linux. If the OS won't support it, then I won't use it.
So, you tell us you are not going to use a system that you weren't going to use.
This guy is a troll. "systemctl daemon-reload" just tells systemd the re-read its configuration files:
daemon-reload
Reload systemd manager configuration. This will reload all unit
files and recreate the entire dependency tree. While the daemon is
being reloaded, all sockets systemd listens on on behalf of user
configuration will stay accessible.
This command should not be confused with the load or reload
commands.
There is no reason to expect it to give an error.
He "forgot" to try launching the broken service after changing the configuration. If he had done a "systemctl start named" he would see the error message and the error status from "systemctl start".
p># journalctl -r -u named | head -5 -- Logs begin at Wed 2015-03-04 19:06:46 UTC, end at Sat 2015-03-07 20:43:55 UTC. -- Mar 07 20:43:55 proxy systemd[1]: Stopped named.service. Mar 07 20:43:55 proxy named[23860]: exiting Mar 07 20:43:55 proxy named[23860]: no longer listening on::1#53 Mar 07 20:43:55 proxy named[23860]: no longer listening on 10.63.228.1#53
There's nothing about the failure to start.
Interesting. Why did you add the 'head -5" there? What was the 6th line output?
Why didn't you use "systemctl status" to see what was going on?
You clearly know a lot about systemd but (deliberatly?) use strange commands to hide information.
systemd will nicely warn you if a unit file for a daemon changed. The output above should have had the warning:
That's interesting, I didn't see this warning when I tried it first -- I'd guess because I installed named for this test and modified the unit file before starting it for the first time. If I modify the file again I see the warning.
Why would you expect "systemctl daemon-reload" to return nonzero? It's "systemctl start" that tells you that named didn't start.
What version of systemd are you testing this on?
Script started on Sat 07 Mar 2015 09:58:01 PM CET [root@centaur ~]# echo '#idiots are idiots' >>/usr/lib/systemd/system/named.service [root@centaur ~]# systemctl start named.service Warning: Unit file of named.service changed on disk, 'systemctl daemon-reload' recommended. Job for named.service failed. See 'systemctl status named.service' and 'journalctl -xn' for details. [root@centaur ~]# systemctl status named.service named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; disabled)
Active: failed (Result: exit-code) since Sat 2015-03-07 21:58:45 CET; 12s ago
Process: 2264 ExecStart=/usr/sbin/named -u named $OPTIONS --broken (code=exited, status=1/FAILURE)
Process: 2262 ExecStartPre=/usr/sbin/named-checkconf -z/etc/named.conf (code=exited, status=0/SUCCESS)
Mar 07 21:58:45 centaur named-checkconf[2262]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Mar 07 21:58:45 centaur named-checkconf[2262]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Mar 07 21:58:45 centaur named-checkconf[2262]: zone 0.in-addr.arpa/IN: loaded serial 0 Mar 07 21:58:45 centaur named[2264]: usage: named [-4|-6] [-c conffile] [-d debuglevel] [-E engine] [-f|-g] Mar 07 21:58:45 centaur named[2264]: [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] Mar 07 21:58:45 centaur named[2264]: [-m {usage|trace|record|size|mctx}] Mar 07 21:58:45 centaur named[2264]: named: unknown option '--' Mar 07 21:58:45 centaur systemd[1]: named.service: control process exited, code=exited status=1 Mar 07 21:58:45 centaur systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Mar 07 21:58:45 centaur systemd[1]: Unit named.service entered failed state.
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended. [root@centaur ~]# exit
Hint: I had an academic course once that covered these methods. It was specifically designed to allow engineers and scientists to identify when they are attacked in this fashion. These are well known methods to sabotage opposition in negotiations, conflicts, etc. Of course such methods are not employed with people that have intact honor and integrity.
You seem to have learned the lesson well.
To reiterate -- you have never made a technical argument about systemd. All your posts are calls to emotion, insults and attempted manipulation.
I agree. such methods are not used by people with intact honor and integrity.
Damned but you are not just a lying troll, you are also an idiot.
Script started on Sat 07 Mar 2015 07:58:37 PM CET [root@centaur ~]# cat/etc/redhat-release CentOS Linux release 7.0.1406 (Core) [root@centaur ~]# grep ExecStart/usr/lib/systemd/system/named.service ExecStartPre=/usr/sbin/named-checkconf -z/etc/named.conf ExecStart=/usr/sbin/named -u named $OPTIONS --broken [root@centaur ~]# systemctl start named.service Job for named.service failed. See 'systemctl status named.service' and 'journalctl -xn' for details. [root@centaur ~]# echo $? 1 [root@centaur ~]# systemctl status named.service named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; disabled)
Active: failed (Result: exit-code) since Sat 2015-03-07 20:00:11 CET; 27s ago
Process: 2344 ExecStart=/usr/sbin/named -u named $OPTIONS --broken (code=exited, status=1/FAILURE)
Process: 2343 ExecStartPre=/usr/sbin/named-checkconf -z/etc/named.conf (code=exited, status=0/SUCCESS)
Mar 07 20:00:11 centaur named-checkconf[2343]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Mar 07 20:00:11 centaur named-checkconf[2343]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Mar 07 20:00:11 centaur named-checkconf[2343]: zone 0.in-addr.arpa/IN: loaded serial 0 Mar 07 20:00:11 centaur named[2344]: usage: named [-4|-6] [-c conffile] [-d debuglevel] [-E engine] [-f|-g] Mar 07 20:00:11 centaur named[2344]: [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username] Mar 07 20:00:11 centaur named[2344]: [-m {usage|trace|record|size|mctx}] Mar 07 20:00:11 centaur named[2344]: named: unknown option '--' Mar 07 20:00:11 centaur systemd[1]: named.service: control process exited, code=exited status=1 Mar 07 20:00:11 centaur systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Mar 07 20:00:11 centaur systemd[1]: Unit named.service entered failed state. [root@centaur ~]# exit
Does gvfs depend on systemd? No, it depends on udev.
Does udev depend on systemd? No.
The source code of udev is in the same directory as that of systemd, but you don't have to install systemd to use udev and removing systemd will not remove udev or gvfs.
I can't help it if you don't know what the word "depends" means in this context.
It doesn't "swallow stderr", it logs stderr output in the journal instead of losing it on the unconnected monitor. See journalctl and systemctl status.
It doesn't "ignore exit statuses", it, unlike sysvinit, knows the exit status of all processes it starts. Check out the systemctl status command.
One of the craziest things about systemd haters is they accuse it of doing the things that sysvinit does, that systemd is explicitly designed to fix.
It's a sad day for ubuntu users everywhere, it's as if a million init scripts cried out in horror.
Among all the craziness about systemd this is one of the best.
Hint -- ubuntu doesn't use init or sysvinit, it's used upstart up to now. upstart is systemd done wrong -- it uses ptrace to keep track of running processes for fucks sake.
And oft repeated claim, that happens to be untrue.
Gnome depends on some facilities of systemd, but those same facilities can be provided by things other than systemd (consolekit, systemd-shim, loginkit, maybe uselessd or systembsd if they get their act together).
Slashdot Mirror
Well, Ben did point out the little problem of Jessie being frozen, you need a bloody good reason to unfreeze at this juncture, and is Chromium important enough?
It's not the "TSYNC feature", it's SECCOMP_FILTER_FLAG_TSYNC
http://lkml.iu.edu/hypermail/linux/kernel/1406.1/01964.html
(Buggered if I know what it's for, however).
Not that I was going to use a system that kowtows to RMS by calling itself GNU/Linux anyway, but the OS is there to support the software I use, and I use Chrome on Linux. If the OS won't support it, then I won't use it.
So, you tell us you are not going to use a system that you weren't going to use.
And we should give a fuck, why?
I just assumed everyone already has BIND installed.
Why the fuck would I install that buggy horror! Next you will be suggesting that I install sendmail.
Why what returned a zero exit status?
With the "--broken" argument added to named.service then "systemctl start named" prints an error message and gives a non-zero exit status.
This guy is a troll. "systemctl daemon-reload" just tells systemd the re-read its configuration files:
There is no reason to expect it to give an error.
He "forgot" to try launching the broken service after changing the configuration. If he had done a "systemctl start named" he would see the error message and the error status from "systemctl start".
So why doesn't it show it when I try?
Why won't you say what version you are using?
why won't you show the systemctl status output?
p># journalctl -r -u named | head -5 ::1#53
-- Logs begin at Wed 2015-03-04 19:06:46 UTC, end at Sat 2015-03-07 20:43:55 UTC. --
Mar 07 20:43:55 proxy systemd[1]: Stopped named.service.
Mar 07 20:43:55 proxy named[23860]: exiting
Mar 07 20:43:55 proxy named[23860]: no longer listening on
Mar 07 20:43:55 proxy named[23860]: no longer listening on 10.63.228.1#53
There's nothing about the failure to start.
Interesting. Why did you add the 'head -5" there? What was the 6th line output?
Why didn't you use "systemctl status" to see what was going on?
You clearly know a lot about systemd but (deliberatly?) use strange commands to hide information.
systemd will nicely warn you if a unit file for a daemon changed. The output above should have had the warning:
That's interesting, I didn't see this warning when I tried it first -- I'd guess because I installed named for this test and modified the unit file before starting it for the first time. If I modify the file again I see the warning.
Why would you expect "systemctl daemon-reload" to return nonzero? It's "systemctl start" that tells you that named didn't start.
What version of systemd are you testing this on?
Nice inversion. Init is the status quo, systemd is the intruder.
In your haste to bash systemd you seem not to have noticed that we're talking about Ubuntu adopting systemd. init isn't the status quo, upstart is.
Anyone hoping to depend on [consolekit[ to get around systemd is going to be disappointed.
Or, rather than being disappointed they could work on loginkit, systemd-shim or systemd-bsd.
But maybe it's more fun to bitch.
Hint: I had an academic course once that covered these methods. It was specifically designed to allow engineers and scientists to identify when they are attacked in this fashion. These are well known methods to sabotage opposition in negotiations, conflicts, etc. Of course such methods are not employed with people that have intact honor and integrity.
You seem to have learned the lesson well.
To reiterate -- you have never made a technical argument about systemd. All your posts are calls to emotion, insults and attempted manipulation.
I agree. such methods are not used by people with intact honor and integrity.
Damned but you are not just a lying troll, you are also an idiot.
Does gvfs depend on systemd? No, it depends on udev.
Does udev depend on systemd? No.
The source code of udev is in the same directory as that of systemd, but you don't have to install systemd to use udev and removing systemd will not remove udev or gvfs.
I can't help it if you don't know what the word "depends" means in this context.
this has NSA written all over it.
No, that's selinux.
Init has 1 binary and only 1 binary, and it does what it does perfectly.
Init does indeed have only one binary, and only one configuration file.
It does its rather limited job quite well.
sysvinit, by contrast, has the whole of /bin, /sbin, /usr/bin, /usr/sbin and fuck knows what else. It does less than /sbin/init can, and it does it badly.
sysvinit doesn't even know whats running, It doesn't know what messages the services it started logged.
With 300+ binaries [ in systemd ] that's a lot of places to have your system go tits up.
That's 70, not 300, and only 8 of them are actually running.
It doesn't "swallow stderr", it logs stderr output in the journal instead of losing it on the unconnected monitor. See journalctl and systemctl status.
It doesn't "ignore exit statuses", it, unlike sysvinit, knows the exit status of all processes it starts. Check out the systemctl status command.
One of the craziest things about systemd haters is they accuse it of doing the things that sysvinit does, that systemd is explicitly designed to fix.
It's a sad day for ubuntu users everywhere, it's as if a million init scripts cried out in horror.
Among all the craziness about systemd this is one of the best.
Hint -- ubuntu doesn't use init or sysvinit, it's used upstart up to now. upstart is systemd done wrong -- it uses ptrace to keep track of running processes for fucks sake.
Perhaps you would like to point to a set of current Gnome packages that dont have any SystemD dependency?
How current do you want?
https://forums.freebsd.org/threads/gnome-3-14-port-is-solid.49299/
Or do you think FreeBSD runs systemd now?
On of the biggest is simple. Gnome depends on it
And oft repeated claim, that happens to be untrue.
Gnome depends on some facilities of systemd, but those same facilities can be provided by things other than systemd (consolekit, systemd-shim, loginkit, maybe uselessd or systembsd if they get their act together).
https://blogs.gnome.org/ovitters/2015/02/24/consolekit-in-gnome-3-16-and-beyond/
systemd has no registry.
systemd has no registry. It does have a bunch of files that look suspicously like INI files.
So you reported this serious security bug when? What is the bug report URL?
Can you explain why this mysterious bug doesn't happen on a newly installed CentOS 7 system?
Thanks for confirming my point: "Systemd is pushed strongly with emotional (not factual) arguments".
It does not get more obvious than you just were.
Projection?
I've never seen you make a techncal argument, just a long list of insults and consiracy theories.
At least on Debian the Gnome requires gvfs, which requires systemd.
No it doesn't:
No dependancy on systemd.