Perhaps PID is the wrong mechanism to talk to a daemon. There’s a mention of control sockets, but not really as a replacement for PIDs entirely. Have each process listen on /var/run/daemon-ctl and you can talk to it without knowing the PID.
It’s not about talking to a daemon. Init system has to keep track of PID so it can catch when the daemon dies. All my services have Restart=always, which means systemd should start it again if the process dies for whatever reason (other than being explicitly stopped with systemctl).
Which it does by …? Polling the system to see which PIDs are alive? At that point, may as well just poll by trying to connect to the control socket.
By virtue of being PID 1, it’ll get a SIGCHLD every time an orphan process (which should be every daemon) dies. That’s the main reason to want your service manager to run in PID 1, really.
PID/signaling is definitely not the right way to talk to a daemon, though.
Oh, ok. I think I’m slow to realize init and the service manager would be the same process. That was probably the point of the article. Oops.
That becomes complicated quickly, once you run multiple instances of the same daemon.
Last weekend I finally made it possible to create a new virtual machine in VirtKick (see the screenshot) and mount an ISO to a virtual machine, even when running.
This week I’ll be adding the final missing part: public network. With this handled, I’ll be ready to deploy VirtKick in production and finally invite folks to the beta tests.
Thought it’s about improving Less so it can compete with Sass. ;)
I’m working on VirtKick, a simple orchestrator. Last week I finished power and storage management. This week I’m making it possible to create a new machine (like on this page in the prototype), and then all the settings from here except for user management.
I’m continuing work on Call to Speakers, my website for tracking open applications for speakers at conferences. I posted it on Hacker News a few weeks ago, and have seen steady growth in Twitter followers. This week I’m working on adding application forms directly to the site, so users won’t have to navigate (often confusing) conference website to submit their talks. Filtering the list of conferences on the front page is also high on the list.
I’ve also been doing API reviews for companies here in SF. I comb through the documentation and play around with an API to find bugs, poorly designed features, and incorrect behavior. It may sound dull, but I find it exciting. It’s a great way to validate all the API work I’ve put in over the last three years. I’m hoping to finish two more reviews this week.
And as always, I’m working on the API at Stripe, addressing performance problems and developing new features. We just had an intern start last week, so I’m helping him get up to speed.
Nice. I pasted to my company Slack, and the preview appeared to be… “foo”. ;-) Be sure to change it.
<meta name="description" content="foo">
Whoops, all fixed :)
Is there anything out there that you would consider to be a good guide to designing (and documenting) a good API? What do you think of things like Swagger?
I’m not a huge fan of Swagger as I think the documentation it generates isn’t user friendly. I’m becoming a fan of Hyper Schema, simply because it’s machine-readable.
I’m working on VirtKick, my open source project for cloud management.
Last week I was implementing the design provided by my UX designer in the clickable prototype. I also did a lot of infrastructure things.
This week I’ll be focusing on the real application - my goal is to get the dashboard and basic virtual machine controls usable.
This looks awesome, both in UX and functionality! Can’t wait to see where it heads.
Thanks, Matt! I’m planning alpha tests in a few weeks - sign up for updates if you’d like to participate. :)