On 9 September 2015 at 20:46, Dhionel Díaz <dd...@cenditel.gob.ve> wrote: > El 09/09/15 a las 16:34, Felipe Sateler escribió: >> Hi Dhionel, >> >> On 9 September 2015 at 17:38, Dhionel Díaz <dd...@cenditel.gob.ve> wrote: >>> Hi everyone, >>> >>> Following the directions in https://wiki.debian.org/systemd/HowToHelp >>> I've attached a service file I've written for the xorp daemon, it has >>> been tested in one of our production routers. >> >> Great! >> >>> >>> I'll be awaiting your review. >>> >>> [Unit] >>> Description=eXtensible Open Router Platform >>> After=network.target remote-fs.target >> >> I don't think remote-fs.target is required here, as having >> DefaultDependencies=yes (the default) ensures all the basic >> filesystems are mounted. > > Ok, I see. I'll remove it. > >> >>> >>> [Service] >>> EnvironmentFile=-/etc/default/xorp >>> ExecStart=/usr/sbin/xorp_rtrmgr $DAEMON_OPTS >> >> It would be better to pass the option to daemonize and make the >> service Type=forking, otherwise systemd does not know when the service >> is successfully started. >> >> Maybe even pass -P and specify PIDFile= so that systemd knows for sure >> what the main process is. > > I'm confused. I thought the recommended approach was to make the service > run in foreground, in order to optimize the startup and monitoring. > Also, as far as I've verified no package depends on xorp; maybe that's > normal for a routing daemon. > > Another reason to implement the foreground behavior was to deactivate > the weekly restart that the logrotate script executes when a pid file is > found; that restart is not longer needed because with the proposed > configuration the log messages are sent to the journal via stderr.
Yes, rotating the log would be irrelevant if the logging is to the journal. > > As an alternative, ¿do you think it would be appropriate to include a > sd_notify call in xorp_rtrmgr main process and then use Type=notify? That would be even better. The problem with Type=simple (the default if no type is specified) is that systemd automatically assumes the service started up correctly. Which can be confusing if eg, the config is wrong: systemd would start the service, then the service would immediately fail. Much better is for systemd to know the service never started up correctly and let you know that. I suggested using Type=forking because it would be less work. The PIDFile is optional, and if xorp only spawns a single process, then it is not necessary at all. > >> >>> TimeoutStopSec=233 >> >> Why this weird value? > > It's just a nice number to specify an almost four minute timeout. The > init script implements a two minute timeout, but in my experience xorp > is rather slow to stop and when the router is highly loaded that might > not be enough time. So I've incremented it using, given the oportunity, > a somewhat special number. OK, this can be overriden by a user anyway if needed. > >> >>> Restart=always >> >> I don't know if xorp can be told to exit, but this would cause it to >> be restarted in such a case. >> > > As far as I've verified, xorp cannot be told to exit via its command > interface (xorpsh); maybe that's also normal in a routing daemon. > Therefore, the rationale was to indicate that the service should always > be available after it's enabled and started. Makes sense. > >>> >>> [Install] >>> WantedBy=multi-user.target >> >> Looks good otherwise to me! >> >> > > Thanks for your time. Thank you for your contribution. -- Saludos, Felipe Sateler _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
