If you don't need the feature, it doesn't listen on any socket.
The default installation on most distros will probably not use socket activation, but some systems will *require* socket activation, just like in the past they required inetd or xinetd.
Ummm. The DEBIAN JESSIE install that I just did yesterday (small mail server) included no [x]inetd.
I didn't ask for it and Debian didn't include it by default.
Just getting used to 'systemd' too..
It didn't install xinetd systemd is the default
# apt-cache search xinetd
?
First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons.
Every modern Unix-like system has inetd or xinetd available, many install one of them by default.
The service we require xinetd for on every production server is: Netbackup's bpcd.
Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.
# readlink -f $(which init)
# netstat -plant|grep systemd
#
How is systemd any different?
(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations.
# systemctl status rsyncd.socket
rsyncd.socket - Rsync Server Socket
Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled)
Active: inactive (dead)
Listen: [::]:873 (Stream)
Accepted: 0; Connected: 0
# cat
[Unit]
Description=Rsync Server Socket
Conflicts=rsyncd.service
[Socket]
ListenStream=873
Accept=yes
[Install]
WantedBy=sockets.target
What is this, a non-text file? How is systemd controlling this, any more than xinetd was?
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
If you can fix it in
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.
No, Linus needs to use his finger.
Absolutely right, though there are still useful things that could be explained: the types of inputs the algorithm accepts, the range of outputs it can potentially give, the model used, etc. In the '90s researchers experimented with building more scrutable models (like decision trees) using a neural net as the training source, with encouraging results [1], but I think the work languished when neural nets went out of fashion.
More importantly, I think this showcases how opaque learning systems (while potentially powerful) may not be appropriate for circumstances when people need to know *why* the system reached a particular conclusion. Predictive accuracy should not be the only metric of concern when developing a machine learning model; comprehensibility of the decision process also needs to be taken into account.
[1] Craven, M. W. and Shavlik, J. W. (1997). Using neural networks for data mining. Future Generation Computer Systems, 13:211–229.
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.
Always try to do things in chronological order; it's less confusing that way.
