Systemd (ptui)

It seems systemd can’t be avoided. I am annoyed at having to relearn stuff for a problem not worth solving. Here are my notes as I learn to use it.

Some links …

  1. The Free BSD man page
  2. from stack exchange, about starting and stopping, and the importance of type=
  3. A tutorial on the commands from digital ocean
  4. I found this at devdungeon.com; it has another example service file
  5. Type= simple or forking, at superuser.com

An example,

[Unit]
Description=A description of the service
After=network.target 

[Service]
Type=simple # check link No 2 & 5 above
User=root
ExecStart=${program_path}/${program_name} 
#       explicit absolute path reqd

[Install]
WantedBy=multi-user.target

It’s like a virus, I had to write a service file for no-ip’s dynamic update client. I remain confused about the choice, but the link from superusr.com above is very clear & helpful.. Wish I’d found it before I had finished.

3 thoughts on “Systemd (ptui)

  1. It may be much more economic in terms of lines of code, although it may just shift logic from the integrated object based lsb init scripts to new start & stop scripts; it should be noted that using scripts other than the service daemon to manage these complicates the work of systemd; it cannot use tupe=simple. (Edited 27/3/2019).

  2. I think there’s a problem with using virtual box file types with systemd; it ought to be possible to define mounts within a service file but this is not the case with virtualbox files. (I think I am still trying to use rc.mymounts to inboke these calls.

  3. I made my first file today, a service definition for noip’s dynamic update client and I have amended the article to more accuratley document or point at documents on type = simple vs forking.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.