Hello, Just a few comments on the proposed .service file:
1) Is it a good idea to pass -d to the daemon? It seems quite verbose in that case, it logs all the upnp request it receives. We could either not use -d flag and rely on the pid file created by the daemon. Or redirect stderr to /dev/null. I would go for using the PID so we are not loosing the important messages printed on stderr. 2) The daemon seems to require a -i argument like in the LSB script. 3) Shouldn't we socket activate the service? It seems that the other software like transmission are querying minissdpd via its socket. Not sure if this is desirable as the application using might query minissdpd before the devices have sent their announcements if it started on demand. This would probably require patching the daemon anyway. We could either use, but we might loose messages sent to stderr: ====== [Unit] Description=keep memory of all UPnP devices that announced themselves [Service] EnvironmentFile=/etc/default/minissdpd ExecStart=/usr/sbin/minissdpd -d -i $MiniSSDPd_INTERFACE_ADDRESS StandardError=null [Install] WantedBy=multi-user.target ====== Or using the PID file created by the daemon: ====== [Unit] Description=keep memory of all UPnP devices that announced themselves [Service] Type=forking EnvironmentFile=/etc/default/minissdpd ExecStart=/usr/sbin/minissdpd -i $MiniSSDPd_INTERFACE_ADDRESS PIDFile=/var/run/minissdpd.pid [Install] WantedBy=multi-user.target ====== -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
