It's pretty rare you need to get that deep into the system.
2017-08-18 11:22 from LoanShark @uncnsrd
Back on that topic, I think I solved my systemd problem. Basically,
systemd thinks it knows whether your service is running or not; it can
be wrong. If your service was invoked directly from the init script, it
doesn't know it's running when it is; if the start script fails,
systemd will think it's running when it isn't; if the stop script
fails, it may think it's not running when it is. Etc. In either of
those states, the "stop" or "start" command may do nothing at all, by
itself, because systemd thinks there's no state transition that needs
It's all a bit boneheaded, but there are ways to deal with it.
PIDFile=[path to your PID file]
If your service creates a PID file, systemd will use the file specified by PIDFile to track whether or not the service is actually running, rather than trying to chase forks in a daemonizing process.
So, if your service can be told to create a PID file, that should help significantly.
If not... well, I dunno how you dealt with it in sysvinit.
And that's why I'd love it if systemd became universal, at least for Linux ... instead of all the tedious mucking about with pid files, you could just run the program without forking into the background, systemd will spawn the process directly and can respond to it exiting.
It's universal enough though, right? It's now the default on both Ubuntu and RedHat-derived systems.
Honestly, if I didn't have to deal with older distributions, I'd stop doing the whole daemonization thing and just run it as you might run any command on a command line.
Hrm... although, honestly, I could do both. I could take a command line argument that would daemonize if needed...
It's universal enough though, right? It's now the default on both
Ubuntu and RedHat-derived systems.
Hmm. According to https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception it has been the default on CentOS, Debian, Fedora, Mint, SuSE, Red Hat, and Ubuntu for some time now (plus some others that I'm not counting as anything other than fringe players).
The question of course is: "as a software distributor, should I write exclusively to systemd?" I'm starting to think the answer is "yes" because anyone still running sysvinit in 2017 is probably already dealing with being a fringe player.
Heh... well, I'm having to deal with ancient distributions, so I still have to write for sysvinit, upstart, and pretty much anything else.
Detecting which init tool the distribution uses is a new kind of entertainment.
In the sense that amputation of major limbs is entertaining.
I figured one had to support sysvinit for backwards compatibility.
I could have taken the easy approach, and just written sysvinit scripts and said 'screw it'. But... I really do want our software to start more dynamically than sysvinit might permit.
For those who haven't seen it or tried it yet...
[ https://guacamole.apache.org/ ]
Guacamole is an access server that requires nothing but a web browser to connect to the RDP, VNC, SSH, Telnet sessions of your choice. One might expect this to be slow and clunky, but it's actually *really* good. It's more responsive than even some non-browser-based clients.
I'm using it now, in fact :)
I wonder how well that works within a virtualized environment. Hmm...
Well, that's the kind of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage...
I've gotta say though, nslcd (aka nss-pam-ldapd) is freaking awesome. Joining a Linux machine to an Active Directory domain used to be a gigantic pain in the ass. Winbind was a piece of garbage, had too many dependencies, and had a habit of just not staying working. nslcd ties the name service switch directly to LDAP, no shims, no gimmicks. It also works with *any* LDAP server, not just AD.
When you have hundreds of servers it's nice to be able to log in with your LDAP credentials instead of having to go into the password vault to fetch the root password.
How badly does it consume bandwidth, doyouknow?
I'd expect if it's using those underlying protocols, it's probably fairly trim.
Oh.... and I wonder if you can record it to an mp4 or something. That'd be super-useful.
I haven't tried using it from anywhere other than my own well-endowed home network yet. I'll report back next week when I'm sitting in an airport using a tethered phone and we'll see. I think it's still going to be pretty good.
And yes, there is a screen recording module available. :)
For my needs, that screen recording thing, if I can route the recording to a server elsewhere, would be amazingly useful.
I've set up a guacamole server/client that shows a proof of concept. It works very, very smoothly... far more smoothly than what we're doing at the moment through our vendor.
That, alone, makes me want to use this. Add to it recording features, and it's all the better... I may play with that tomorrow.
It's a tad frustrating, though, that I couldn't get the same familiar desktop in linux as the console's desktop (meaning, as if a CRT were connected to the VM, if that were possible). That's a bit of a shame, and might be a problem for certain distributions (Security Onion, Kali, etc). I dunno... maybe I can work around that somehow.
It would be easier if Guacamole could natively speak X11 and XDMCP. Although Guacamole has been designed to be extended in this way, no one has written this protocol yet.