On Fri, Jun 26, 2015 at 4:15 PM, Lesley Kimmel <ljkimme...@hotmail.com> wrote:
> Hi all; > > I've been working with RHEL5/6 for the past several years and have > developed many init scripts/services which generally use lock files and PID > files to allow for tracking of the service status. We are moving to RHEL7 > (systemd) in the near future and I am looking for instruction or tutorials > on how to effectively migrate these scripts to work with systemd. > > I found https://wiki.archlinux.org/index.php/Systemd#Service_types which > seems somewhat promising but it is fairly high-level. It looks like I may > be able to use the 'forking' type with the 'pidfile' parameter to somewhat > mimic what the scripts to today. However, I have a couple of questions: > Usually systemd detects the main process even without PIDFile, using cgroups to keep track. > -How does systemd track whether it should be stopping a service at > shutdown (analogous to the /var/lock/subsys files in SysVInit)? > All service control requests go through the always-running init process, so it can just keep track of service status internally without having to write it out. [This also means services run in a clean environment and can't ask for interactive input when starting. Upstart and even /etc/inittab also work the same way.] Systemd also monitors whether the service processes are actually running – by putting each into a separate cgroup – so it generally avoids issues such as stale pidfiles. > -Are there merits to using the notify or dbus types? If so does anyone > know of a tutorial I could use to get to that point? (FYI, I'm not a > developer but I learn complicated things quickly). > Similar to Type=forking, they both let systemd know whether the service is ready or still initializing (which can't be done with the default Type=simple). Type=dbus might be best for creating DBus-activatable services compatible with regular dbus-daemon, since it has mostly the same expectations as dbus-daemon: the service doesn't fork, and is considered ready as soon as it finally claims the configured BusName. Type=notify is somewhat more lightweight – the service just needs to send READY=1 over a Unix socket. (The service can also show some additional information in `systemctl status` – e.g. lldpd could send "STATUS=No neighbors"). libsystemd has sd_notify(3) <http://www.freedesktop.org/software/systemd/man/sd_notify.html> for this, though it could be done using regular socket API. I suppose the same notify socket could be exposed to all other service types. I don't know why it isn't yet. > -If the current service logs to a custom, dedicated log is there a way to > get systemd to provide the same type of output that it does for the > built-in system services or must I make some modifications to integrate > with journald? > `systemctl status` only reads from the journal. The journal, however, also receives messages sent using the traditional syslog API or written to the kernel log – in addition to its native sd_journal_send(3) <http://www.freedesktop.org/software/systemd/man/sd_journal_send.html> – so that already covers most services. You could also use rsyslogd to feed messages from custom text logs into the journal, using its omjournal module. -- Mantas Mikulėnas <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
