hi, the default service configuration file mentions the username used to run the service (USER=milter) but the variable is never used. Though, the -u milter is hardcoded in the options for the service. Here is as it is found in /etc/conf.d/sid-filter USER="milter" SID_FILTER_OPTS="-u milter -l -p $SOCKETSPEC -d $DOMAIN" but it should be USER="milter" SID_FILTER_OPTS="-u $USER -l -p $SOCKETSPEC -d $DOMAIN" Reproducible: Always
Another thing with the user part from sid-milter is that if you switch the user in the conf.d file and then kill sid-filter (for whatever reason) and then start it again it will not be able to create the pid file. One possible solution for this issue would be to add something like this here to chown the pid file should it not be owned by the user starting sid-filter: --------------- local user_flag= filter_user= for foo in ${SID_FILTER_OPTS}; do [ -n "${filter_user}" ] && break [ -n "${user_flag}" ] && filter_user=${foo} [ "${foo}" == "-u" ] && user_flag=1 done if [ -n "${filter_user}" ]; then touch /var/run/sid-filter.pid chown ${filter_user} /var/run/sid-filter.pid fi ---------------
Fixed in cvs with rev bump.
(In reply to comment #2) > Fixed in cvs with rev bump. > Would have been nice if you had not only changed the $Header line but the Copyright as well: > #!/sbin/runscript > # Copyright 1999-2006 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: /var/cvsroot/gentoo-x86/mail-filter/sid-milter/files/sid-filter.init,v 1.2 2009/12/05 06:49:37 mrness Exp $
(In reply to comment #2) > Fixed in cvs with rev bump. > The new init.d script is now reporting crashed state regardless how many domains I use. Now I have the behavior like mentioned in bug # 293090 but this time with just one single domain entry. Not good :(
Created attachment 212147 [details] sid-filter.init This modified init.d script brings back again the old behavior. I dropped the --background and --pid-file options for start-stop-daemon since sid-filter does anyway fork into the background and anyway is capable to create a pid file on it's own. I still have the same issue with sid-filter being reported as crashed when using more then one domain (-d switch) on newer editions of Portage while everything done by the init.d script is as it should be: --------------------------- theia ~ # /etc/init.d/sid-filter restart * Caching service dependencies... [ ok ] * Stopping Sender-ID Filter... [ ok ] * Starting Sender-ID Filter... [ ok ] theia ~ # /etc/init.d/sid-filter status * status: crashed theia ~ # cat /var/run/sid-filter.pid 3092 theia ~ # ps auxww|grep -i sid milter 3092 0.0 0.0 26888 1108 ? Ssl 12:53 0:00 sid-filter -P /var/run/sid-filter.pid -B -T 10 -a /etc/mail/opendkim/PeerList -d vunet.local localhost.localdomain -h -l -p inet:8026@127.0.0.1 -u milter root 3174 0.0 0.0 1940 572 pts/0 S+ 12:54 0:00 grep --colour=auto -i sid theia ~ # --------------------------- This is IMHO a bug in Portage. Don't ask me what is triggering it but it's a bug. The pid file is there, has the right process id, the process is running, etc and yet Portage thinks it is crashed. Anyway... that issue is already reported in bug # 293090 and has nothing to do with this bug here.
Created attachment 212149 [details] sid-filter.init Removed the --quiet option from start-stop-daemon and the value check for ${filter_pid} since I force a value for ${filter_pid} in parse_opts().
I've updated init script with a cleaned up version of the one attached here, but I didn't bumped the revision.
(In reply to comment #7) > I've updated init script with a cleaned up version of the one attached here, > but I didn't bumped the revision. > Alin. Might I ask you why you change things WITHOUT bumping the revision? Is the revision mechanism not made exactly for that? I mean: You change something -> bump revision. Do you know how hard it is to operate Gentoo (and ensure quality assurance) when you can not relay on version and revision of the ebuilds? Or is there something special regarding when to bump and when not? I always was under the impression that any change to an ebuild automatically results in a revision bump. The only ebuilds that I see excluded from this mandatory revision bumps are SVN/GIT/CVS/live ebuilds. But all the others should IMHO be bumped whenever they get changed. Or have I not understood how the revision is handled in Gentoo? Can you point me to dev documentation explaining when to bump and when not?
(In reply to comment #8) > Can you point me to dev documentation explaining when to bump and when not? http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
(In reply to comment #9) > (In reply to comment #8) > > Can you point me to dev documentation explaining when to bump and when not? > > http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html > THX
