Dipping my toes into Linux recently, I felt a need to support systemd for starting some customer services. It was, initially, a major pain in the ass to figure out why something wasn't quite working correctly, but eventually I worked through the problem (the code was not quite working correctly, but system v approaches hid the issue), and got it to work reasonably well.
I'm still a little fuzzy about how it deals with dependencies... most specifically, the various names for various dependencies, which can be different depending on distributions... but I muddled through.
Philosophically, though, I don't like systemd. Unix has a tradition of 'do one thing, and do it well,' that systemd violates from what I can see. It feels to me as if systemd needs to be broken down into more discrete pieces that have a common api through which to communicate.
uptime13:07:37 up 33 days, 19:33
It is so disapointing when linux makes me reboot. I really would like to get my desktop to go for months
without a reboot.
How long have we been on this lifeboat?
Thirty-three days, sir?
Dipping my toes into Linux recently, I felt a need to support systemd
for starting some customer services. It was, initially, a major pain
The problem now is that if you're packaging an application you have to support *both* sysvinit and systemd. Although systemd can be configured to honor sysvinit scripts, there is no guarantee that your underlying OS has it built that way.
What a pity, I really enjoyed just running services directly out of /etc/inittab, with each service's "don't go into the background" flag set. If a daemon crashed for whatever reason, init would just restart it. The "upstart" init replacement which was included in nonstandardbuntu for a while had a way to configure auto-respawns, but one line in inittab was TEH R0X0R.
Now, if it doesn't exist already, someone's going to have to write an "install this as a service" script that feels-out the underlying environment and does the right thing.
The tricky bit, for me, was dealing with the daemonization of the service.
systemd can react in one of three ways, if I recall, to this... it can expect the executable to run as if it were being run on a command line, without relinquishing control and all that. It can expect the executable to run as if it were fully daemonized (gives up the console, pushes itself in the background, and all that jazz). And I forget the third option... but I think it's kind of a half-way between those two.
But detecting that is apparently non-trivial. I forget the name of the tool I used to trace what was going on with my executable, but it didn't do a great job of informing me of what was happening with the spawned threads, and I think it did nothing to tell me of whether or not the console was relinquished.
That said, the only other tricky bit involved ensuring other things that I needed running were in fact running when my service started. But, y'know, Windows has this problem, too. I think systemd is more flexible in its approach, but it's complicated. Like a lot of relationships.
Hm... dunno what consequences exist if you don't daemonize the code and let systemd deal with it. Maybe none... although writing your code to work only with systemd might not be ideal if you want your stuff to work on other systems.
Well, if systemd takes over the universe, we'll eventually get to the point where the few init scripts that are left will have ampersands in them.
They seem to have a pretty good run, but Solaris will not likely shift to that model. We'll have init scripts for a long time yet.
Make sure you update.
Hrm... I don't expect you're looking for something like:
(by way of enumerating services)
Gah, I didn't even get that right...
This said, apparently, Red Hat prefers 'systemctl' commands.
To list services:
systemctl list-unit-files --type service
unless you're talking about an old Red Hat. Older Red Hat apparently did:
netstat -an | grep LISTEN. Find out what process owns those ports, whether they are truly necessary for your use case, and if not, shut them down.
next, think about local security. Can you enable selinux in strict mode without breaking anything critical?
Red Hat used to have a simple "enable the firewall" script that would install some basic packet filters. I don't remember the name of it anymore, might have been system-config-firewall
Use the "find" command to hunt down setuid/setgid binaries that might not be necessary.
This is basic stuff. I'm not a security guru anymore, if I ever was. Google "Red Hat hardening" or something.
List listening sockets and proggies):
List the users of the port, and userid:
lsof -ni :portnumber
lsof -ni :25
Show the individual process info:
(and many other items under /proc/[pid] that interest you (cat is your friend).
Feel free to share anything you learn as well.