Anyway if they can get to the virtual console they're probably already in a position to shut the whole server off anyway.
I liked being able to "see it running" very easily, whether it was Netware or Lotus Notes or whatever. I liked being able to connect to the console and have the ability to type stuff at it. Asterisk does this pretty well, actually. If you have the authority you can connect to the console and see everything it's doing and enter commands, and disconnect without stopping the server.
Going forward though, it's pretty simple. systemd won't need your program to daemonize at all, but when you do need to go into the background, a simple call to daemon(0,0); does the trick. I'm not sure which of those imitation Linuxes like FreeBSD or Mac OS or Solaris it works on, though.
It looks like the FreeDesktop folks have written a bit of a field guide for us, though:
[ https://www.freedesktop.org/software/systemd/man/daemon.html ]
I recently stumbled across a tool called "winexe", which lets you remotly connect from a linux box to a windows box in order to execute a command there, cmd.exe for example.
A groupware distribution for schools uses this in a very neat way: You join a windows machine to its samba nt4 domain, you use the webinterface to install the opsi-agent via winexe and then you are able to install a large amount of software via OPSI itself. I have to study their configs in order to replicate that for my other clients.
Groupware distribution: https://iserv.eu/ (german only, as it seems)
Winexe: https://lbtwiki.cern.ch/bin/view/Online/WinExe (source via sourceforge, sadly)
OPSI (Open PC Server Integration) is an software distribution tool, which also lets you keep taps on installed software, some license keys and the hardware: http://www.opsi.org/en
Subject: Systemd uber.
I have butted heads with Patrick Volkerding before (on the topic of including PAM in the mainline of Slackware) - and failed back in the late 90's. What would you suggest to help him take in Systemd as a "good thing" - Martha Stuart "T.M."
I don't have enough education on System D to make an educated guess as to what is best for the future of Linux, but it sounds like you do.
This URL does a reasonably decent job of describing the problem that systemd (and other such tools) solve:
Problem is, right there in the article, they note that Patric Volkerding views systemd as the attitude of the key developer for the tool towards users and bug reports doesn't seem to be good. That kinda suggests the tool might struggle not because of its technical merits, but because of it handlers.
For my part, I struggled a little to find simple documentation for how I would modify my setup to embrace systemd, and had to learn much of what I know through trial and error... and I'm still not sure I quite grasp the way they handle dependencies (which might be a matter of poor documentation on the part of the OS distributor, or how systemd is a tad too loosy-goosy about defining things such that you can reliably spell out your dependencies).
Gads.. but that's not the best use of English there.
The article notes Volkerding doesn't view the maintainer of systemd as being good towards users and bug reports. And I guess some of these guys feel its philosophy is 'weird,' not quite matching the unix ideal for controlling system processes.
What 'good' means, I don't know. I guess maybe the maintainer isn't responsive, or is overly dismissive, or ... something?
"I'll be here again with another Interesting article you people will love to read."
If I thought the author had good English skills, I'd find that offensive.
Instead, I think he doesn't quite intend what he wrote.
Why put systemd in every distribution? If all distros were alike, we wouldn't need so many of them.
imho, this old system where you manually enumerate initscripts to determine boot order was bad. I hated it in SuSE.
Gentoo for example uses openrc, where you define the the dependencies of an initscript and then it all gets resolved automatically. I like that. I like Gentoo. IIRC, arch used it for a while, too.
I have yet to get used to systemd, since it will be in every major distro in the future. Wether that is a good thing or not. Until now, I maintain mostly Centos6 based systems.
Subject: Look what I just found...
The following command, when run as any user, will crash systemd:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
After running this command, PID 1 is hung in the
pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that's short enough to fit in a Tweet.
Neato! That worked rather well on Ubuntu 16 server.
Hm, this didn't work on Kali 2.0, though, which also uses systemd. I wonder why that didn't bother it.
Wait a moment... nope... it looks like it did impact it. I can't restart the box properly. It doesn't seem to mind letting me start/stop services, though.
Subject: Re: Systemd uber.
I don't think it can be done. :)
Slackware isn't really a Linux operating system. It's FreeBSD with a Linux kernel.
That having been said, here are the technical reasons I like systemd. I don't really care to get into the religious war on this one -- in fact, people who dislike systemd are *not* necessarily Hitler. I happen to personally like it because:
* It is a single subsystem that replaces dozens of scripts that can interact in weird ways.
* Installing a new service is simple, and done one way: "systemd enable <svcname>" (assuming you dropped the systemd config in the one proper directory where it is expected to be found).
* systemd does not require specially-formatted comments to be placed in init scripts to give the OS a hint as to ordering and dependencies. Instead, its configuration syntax has proper dependency management.
* Services started by systemd do not require extra code to place themselves into the background (daemonize). Therefore, they don't have to drop pidfiles onto the system so that some other script knows how to shut them down later.
* If a service started by systemd crashes, systemd can respawn it automatically.
Back when sysvinit was ubiquitous, I used to start services directly from /etc/inittab for exactly that reason. systemd offers this ability in a more formal declaration syntax: here's the program; run it in the foreground; if it exits, fire it up again.
sysvinit was designed to be configured by greybeards; systemd was designed to be configured by installation scripts. For that reason alone, it makes more sense for mainstream Linux distributions to be using systemd. Slackware isn't really a mainstream Linux distribution though.
Does it even have the normal init scripts? It's been a long time since I looked at Slackware, but the last time I used it, it had /etc/rc.d style scripts.
Like I said ... FreeBSD with a Linux kernel.
Subject: Re: Systemd uber.
So, automation and daemon management. Slackware has rc init scripts (BSD). Never had issues with them, but I mostly use Slackware in cases of set up once and run till it dies cases (one off routers, single board computers with one task, etc...).
I did not mean to invoke a vi vs emacs type holy war. Just wondering what sysadmin type tasks you found to be helped by using systemd, and what I could do differently with my Slackware installs if they ran it, but for what I do with them, it probably won't help much.
Thanks, I think I see the benefits. I run systemd at work on a couple of machines so far, and the learning curve has been a fair amount of digging up documentation with each new line in syslog to see what might need tweaking next. I know it does logging (journalctl), and have started using it as well, but I find it hard not to fall back to reading syslog :-)
Most of the automation I do uses fabric helper scripts to keep my ever growing farm of pets (i.e. not cattle) alive.
Hoping to work in to more automation and cattle servers in the near future though.
The more I look at Docker, the more I'm convinced that it could potentially become *the* universal package distribution format for third-party software.
I think I was looking at it the wrong way, assuming that it served the same purpose as Virtuozzo/OpenVZ or LXC by itself -- basically just a more lightweight version of a virtual machine that uses a shared kernel and cannot easily be live migrated. And maybe that's marginally useful, but probably not enough to justify using it instead of actual virtual machines, except maybe if you needed exceptionally high density on a single host.
But now that I'm playing around with it I see that the real value is that a Docker image carries around all of the dependencies for an application, so there is literally nothing that can go wrong. And the image format being git-like so that it can not only be expressed as deltas from a parent image, but also pool those deltas on a central repository, is sheer genius.
I installed Docker because I was trying to build an application that had a lot of steps to put all of the pieces together. In the past, application providers might have solved this problem by distributing the application as a virtual appliance. But they chose to go with Docker instead. I downloaded the container and ran it. Everything came up on the first try.
I'm definitely going to start distributing my software this way.
Try OnlyOffice... it seems to have dependencies on other docker apps, which seems somehow kind of fucked up.
You might expect binaries to have dependencies, but there's something ... wrong ... about docker dependencies.
Now you've got a ship-shipping ship shipping shipping ships, which can't ship ships without... a tugboat.