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.
Wow, this is funny and pathetic at the same time. I found this on the web site of a fairly popular piece of software today:
$i_understand_file_permissions_and_how_to_fix_them = false;
$i_understand_file_permissions_and_how_to_fix_them = true;
Now you have the button, the following explains the issues in detail."
Hmmm... someone has obviously been torn between wanting to help people, and not wanting to deal with the same stupid problem repeatedly.
LOL. The real problem is using anything written in PHP ;)
Yeah, I'm trying to migrate us to rails.
LOL. The real problem is using anything written in PHP ;)
Real developers write web applications in C.
(Ok, maybe not. But PHP does have a tendency to encourage an unhealthy mingling of markup and code.)
The software in question here is a Cacti plugin. And yes, I'm sure the developer was very frustrated with getting the same stupid question over and over again.
As many of you know, I've dealt with this. It's not a fixable problem. When you make a piece of software easier to use, you simply move to a lower stratum of people who have an even stupider problem. It's infinitely nested and there is no bottom.
(Ok, maybe not. But PHP does have a tendency to encourage an
unhealthy mingling of markup and code.)
That can be worked around. The semantics are horrible... take a look at the truth table for the == operator.
I still maintain that PHP was never meant to be a serious language but it "had greatness thrust upon it" by baristas-turned-programmers during the dotcom years.
The language selection wasn't what I was focusing on, though. Even a unix superfan like me can appreciate the fact that when you throw people out there into the world of file permissions without giving them the right mental tools to deal with it, bad things can happen. That developer's approach was snarky, which I totally love. It won't work, though. People ignore clearly written instructions and ask stupid questions anyway.
(Just do a "chmod -R 777 /" and everything will be ok!)
Hey, at least on a mainframe, file permissions are an add-on feature. So you can just shut off RACF and everything "just works" :)