Hi, Why there is not ulogd.service for systemd? I'm not a developer but below paste first version. Please do it better and put to portage. tnx. j [Unit] Description=Userspace logging daemon for NFLOG After=network.target [Service] ExecStart=/usr/sbin/ulogd -c /etc/ulogd.conf --uid ulogd --pidfile /run/ulogd.pid PrivateTmp=true TimeoutSec=10 [Install] WantedBy=multi-user.target
(In reply to Jacek from comment #0) > Hi, > > Why there is not ulogd.service for systemd? Hello. Because it is not provided by upstream and I don't have systemd on any of my machines. I'll work on this issue. Thanks for the initial version.
Created attachment 402632 [details] ulogd.service Hello again. Sorry for the delay on this one. Here is the updated systemd service file. Jacek, can you try it on your machine, please? I've tested it inside a VM and it works fine, but I'd like to know if it works in a real world setup. If somebody from @systemd team could give it a look and provide feedback, it would also be much appreciated. @proxy-maint team do not yet commit this file to the tree, please. ulogd-2.0.5 was released recently and I'd like to have this file added together with the ebuild for 2.0.5, which I am already working on. Thanks.
works ok for me. tnx
What is the reason for forcing it to fork with the --daemon option?
To quote our wiki page: > Use of Type=forking is appropriate if the exit of the parent process allows systemd to detect failures at startup, before other dependent units are started. Otherwise, use Type=simple if possible by running the daemon in the foreground. Is the former case applicable here?
(In reply to Pacho Ramos from comment #4) > What is the reason for forcing it to fork with the --daemon option? Because otherwise ulogd stays in foreground. On the second thought it may be possible to avoid this and convert service to Type=simple and remove PIDFile option. I'll try that.
(In reply to Mike Gilbert from comment #5) > To quote our wiki page: > > > Use of Type=forking is appropriate if the exit of the parent process allows systemd to detect failures at startup, before other dependent units are started. Otherwise, use Type=simple if possible by running the daemon in the foreground. > > Is the former case applicable here? I don't know yet, but I'll try running ulogd in foreground.
Let me restate my question: Does forking allow systemd to detect failures during startup? If so, forking is fine.
I've tested a bit more and your ulogd.service starts and stops ok like mine, but in case of any errors eg. bad config file, my scritps shows more details in journal. Probably because of forking. j
* app-admin/ulogd Available versions: 2.0.3 2.0.4 {dbi doc json mysql nfacct +nfct +nflog pcap postgres sqlite} @proxy-maint team do not yet commit this file to the tree, please. ulogd-2.0.5 was released recently and I'd like to have this file added together with the ebuild for 2.0.5, which I am already working on. Do you still wish to await the bumping to ulogd-2.0.5
(In reply to Ian Delaney from comment #10) > Do you still wish to await the bumping to ulogd-2.0.5 Yes, please. ETA on this one and ulogd-2.0.5 introduction is 1-2 days. I just need to finish few remaining things at my primary job. I am sorry for the delay.
(In reply to Coacher from comment #11) > (In reply to Ian Delaney from comment #10) > > Do you still wish to await the bumping to ulogd-2.0.5 > > Yes, please. ETA on this one and ulogd-2.0.5 introduction is 1-2 days. I > just need to finish few remaining things at my primary job. I've dealt with all the things I was supposed to do. I'll work on this bug today and upload ulogd-2.0.5 later in the evening.
Created attachment 403896 [details] ulogd.service Hello. Here's an updated version of ulogd systemd unit file. Now it does not explicitly execute ulogd with --daemon option and unit type is "simple". Thanks to Pacho Ramos and Mike Gilbert for pointing this out. (In reply to Mike Gilbert from comment #8) > Let me restate my question: Does forking allow systemd to detect failures > during startup? If so, forking is fine. In this case forking is not necessary. systemd was able to detect startup failures in all of the several cases I've tried (missing config, misconfiguration, etc.) with this unit file.
(In reply to Coacher from comment #13) > > (In reply to Mike Gilbert from comment #8) > > Let me restate my question: Does forking allow systemd to detect failures > > during startup? If so, forking is fine. > > In this case forking is not necessary. systemd was able to detect startup > failures in all of the several cases I've tried (missing config, > misconfiguration, etc.) with this unit file. Assuming the daemon is correctly written (fork happens after it is initialized and listening/etc), with forking you'd generally get the benefit that dependent processes would not start if there was a startup failure. Without forking the failure would be detected, but dependent processes might have already started by then, since the unit is considered running as soon as its process is started. With forking unit isn't considered running until it forks, and so a failure before then causes downstream units to fail as well (or at least not start - I forget if they are marked as failed). I don't know if anything actually depends on ulogd though.
Awaiting the release and appearance of ulogd-2.0.5
(In reply to Richard Freeman from comment #14) I see. Thank you for the detailed explanation, Richard. iptablesweb[0] is the only program I am aware of that specifically depends on ulogd. But it appears it was not updated since 2006 and is also missing from the portage tree. Various log analyzers, e.g. logstash[1], can use the functionality provided by ulogd, but it is not a hard dependency for them. Taking this into account I think we should leave ulogd systemd unit being `Type=simple` as it is now (in the attachments). Should the need arise we can always switch to `Type=forking`. [0]: http://iptablesweb.sourceforge.net/ [1]: https://github.com/elastic/logstash
(In reply to Ian Delaney from comment #15) > Awaiting the release and appearance of ulogd-2.0.5 Actually the bugreport is there already. See #550330.
(In reply to Coacher from comment #16) This is not just limited to units that have reverse dependencies. For daemons that properly implement forking, Type=forking also allows "systemctl start" to detect failures immediately. For example, take unbound, which reads a config file /etc/unbound/unbound.conf. If the config file is missing, it exits immediately with a non-zero status. % sudo mv unbound.conf unbound.conf.bak % sudo systemctl start unbound.service Job for unbound.service failed because the control process exited with error code. See "systemctl status unbound.service" and "journalctl -xe" for details. If unbound.service had Type=simple, systemctl start unbound.service would have succeeded with no immediate feedback for the sysadmin.
*ulogd-2.0.4-r1 (30 May 2015) *ulogd-2.0.5 (30 May 2015) 30 May 2015; Ian Delaney <idella4@gentoo.org> +files/ulogd-2.0.5-remove-db-automagic.patch, +files/ulogd.init, +files/ulogd.logrotate, +files/ulogd.service, +ulogd-2.0.4-r1.ebuild, +ulogd-2.0.5.ebuild, -files/ulogd-2-ng.init, -files/ulogd-2.logrotate, -ulogd-2.0.3.ebuild, metadata.xml:
(In reply to Mike Gilbert from comment #18) Thank you for the further explanation, Mike. ulogd unit with `Type=forking` behaves the same way as you described in your comment and allows to detect failures immediately. I can see that this a useful feature. Right now ulogd unit in tree has `Type=simple`. I'll ask @proxy-maint team to update it.
Thanks to everybody who helped with this bug and especially to @systemd team.
