3 ms·

I haven't tried this, but it sure looks handy. Writing a daemon is a common task, but not so often (for me, anyway) that it feels like copy-and-pasting the same

I haven't tried this, but it sure looks handy. Writing a daemon is a common task, but not so often (for me, anyway) that it feels like copy-and-pasting the same boilerplate every time. So, I ignore the old rule that says "if you're going to do it more than once, write a program to do it for you". I always end up writing a one-off prototype for my own personal use, and then upgrading it to be a daemon, and I make the same Google searches every time. I'll have to try this next time.

mahmud 17y ago
writing a daemon is not necessarily a repetitive process, all the stuff that you "have to do" are driven by engineering demands. You have to think of them consciously before you do each one and there is no particular number of them and no particular order, it's all dictated by your application: when to fork and let the parent die? when to give up terminal? change directory? reset/change umask? what file descriptors to close which ones to open and what to keep? logging? other IPC channels for client apps? etc. this stuff is not cruft or boiler-plate is it? also, you shouldn't be writing daemons so often as to need a framework, and if you do, you better understand all that goes into it.
- DannoHung 17y ago
  I'd like to learn more about daemons to satisfy my own personal curiosity. Do you have any resources you recommend?
  - alxv 17y ago
    Richard Stevens's "Advanced Programming in the UNIX Environment" has a chapter dedicated to how to write well-behaved daemons. The book is a great investment if you are doing any kind of UNIX programming; I highly recommend it.
- stratomorph 17y ago
  I agree that it's not boiler-plate, and I don't mean that I do it all that often, maybe every six months or so when I find something new I want my home server to do. (Like the last one, experimenting with port knocking) I am by no means a professional programmer, that's why I find myself making the same searches.
  - mahmud 17y ago
    Cheers! didn't mean to come off so nanny-like ;-)

mahmud 17y ago

writing a daemon is not necessarily a repetitive process, all the stuff that you "have to do" are driven by engineering demands. You have to think of them consciously before you do each one and there is no particular number of them and no particular order, it's all dictated by your application: when to fork and let the parent die? when to give up terminal? change directory? reset/change umask? what file descriptors to close which ones to open and what to keep? logging? other IPC channels for client apps? etc. this stuff is not cruft or boiler-plate is it? also, you shouldn't be writing daemons so often as to need a framework, and if you do, you better understand all that goes into it.

DannoHung 17y ago
I'd like to learn more about daemons to satisfy my own personal curiosity. Do you have any resources you recommend?
- alxv 17y ago
  Richard Stevens's "Advanced Programming in the UNIX Environment" has a chapter dedicated to how to write well-behaved daemons. The book is a great investment if you are doing any kind of UNIX programming; I highly recommend it.
stratomorph 17y ago
I agree that it's not boiler-plate, and I don't mean that I do it all that often, maybe every six months or so when I find something new I want my home server to do. (Like the last one, experimenting with port knocking) I am by no means a professional programmer, that's why I find myself making the same searches.
- mahmud 17y ago
  Cheers! didn't mean to come off so nanny-like ;-)