All courier related init scripts fail with our new baselayout version because we now do some tricks with start-stop-daemon to ensure daemons start and stop correctly. This relies on start-stop-daemon being sent a daemon to start. However, the courier scripts send /usr/bin/env as the daemon. Some other scripts do this and it normally works. However, env then calls a shell script (in authlibs case it calls "-" as thats apparently the first parameter - it can be removed and it should work then) As such, we fail to work as neither env or the shell script are daemons. More correct behaviour would be to remove the call to start-stop-daemon as neither env or the shell script are daemons. Or you could re-write the init scripts so they're proper init scripts instead of just shelling out and calling another script.
Mass re-assign, seems like mail-mta/courier needs a maintainer.
Apologies if this falls under a courier script, but wpa_supplicant fails with the new baselayout with a "-a" is not an acceptable parameter, and the system never fully boots up. Once I backed down to baselayout-1.11.13 it worked again.
nope, nothing at all to do with courier, try searching for wpa_supplicant bugs, or file a new one
Adding an --oknodo to start-stop-daemon --start in the init script makes it work again. Not sure if this is a good solution though. Same for mysql.
*** Bug 99750 has been marked as a duplicate of this bug. ***
I am in the process of rewriting the init scripts to be true init scripts rather than the *cough* hacks *cough* they appear to be... Will post authlib and imap/imap-ssl w/n 24hrs, and I'll try and squeeze in the pop ones at some point... I don't use courier as my MTA though, rather using postfix, but if people _really_ want init scripts for the rest of the courier packages i'll see what i can do. -cc
Created attachment 64082 [details] /etc/init.d/courier-authlib replacement Ok, here is a replacement for the init script... going to also attach a file to go in /etc/conf.d/courier-authlib. i removed a fair amount of cruft, moved the environment variable setup to the conf.d file to standardize the look & feel, and took out the unnecessary use of env. I have not tested this script w/o courierlogger, i simply included _something_ should that variable not be set correctly... perhaps should force the use of a logger, and throw an error instead of trying to continue, as it seems really designed to go inside of the logger. Thoughts? Comments? I'm now investigating the imapd init scripts, and I am beginning to wonder what on earth is going on with them... they will probably be more radically changed. Hope someone is interested in these. -cc
Created attachment 64083 [details] /etc/conf.d/courier-authlib the cond.d file to go with above. please note, you will need to rename these files. i gave them extensions so i could work on them in a local directory. -cc
Well... having explored the depths of the courier-imap package... I have found a huge desire to switch to a different IMAP server. There is no reason for the amount of pain involved with courier. If people really _really_ want this ebuild fixed... i suggest the hack solutions already posted. -cc
I don't see start-stop-daemon used in courier's init scripts anywhere. Are you referring to courier-imap?
(In reply to comment #10) > I don't see start-stop-daemon used in courier's init scripts anywhere. Are you > referring to courier-imap? s'cuse me... was reffering to courier-imap, but it didn't use start-stop-daemon (much). Only used it to kill off the processes as far as I could tell, while it managed starting on its own. courier-authlib acually used (incorrectly) the start-stop-daemon. -cc
Created attachment 64113 [details] courier-imapd How to write in init script properly 101 :)
Created attachment 64114 [details] courier-imapd-ssl These use start-stop-daemon correctly and are pure drop in replacements which work. I'll port the pop3 ones if I get time later this weekend.
Courier (which is the name of a seperate package in portage) seems to be just fine. It's courier-imap and courier-authlib that are not in good shape.
Created attachment 64132 [details] courier-pop3d
Created attachment 64133 [details] courier-pop3d-ssl These pop3d ones appear to work fine, but I have not tested them. I am also unsure about how I have handled the PRERUN variable as I can find no good documentation on how it is expected to behave - aside from that all 4 are straight drop in replacements working with start-stop-daemon. Yay!
Created attachment 64245 [details] courier-imapd-ssl Whoops - check ${SSLPIDFILE} and not ${PIDIFLE} Fixed :)
it surely worked for me :) say... when those init scripts will be in the portage tree?
PRERUN should be executed with the couriertcpd
For courier-pop3d (non-ssl) usr/sbin/pop3login should be /usr/sbin/pop3login
Created attachment 64989 [details] courier-pop3d You're right :)
(In reply to comment #19) > PRERUN should be executed with the couriertcpd Can you provide a working patch to the init scripts attached here?
I have tried but the start-stop-daemon is missing eval eg it should be (according to the old scripts) something like start-stop-daemon --start --exec eval ${PRERUN} \ /usr/lib/courier-imap/couriertcpd \ --pidfile "${PIDFILE}" -- \ -address="${ADDRESS}" \ -stderrlogger=/usr/lib/courier-imap/courierlogger \ -stderrloggername=imapd \ -maxprocs="${MAXDAEMONS}" -maxperip="${MAXPERIP}" \ -pid="${PIDFILE}" ${TCPDOPTS} \ "${PORT}" /usr/sbin/imaplogin \ /usr/sbin/courier-imapd "${MAILDIR}" With the current way, we get this error message: relay-ctrl-chdir[6470]: Fatal: usage: relay-ctrl-chdir program [arguments]
What do I have to emerge to test PRERUN that won't put too much on my system? I think we're going to need something a bit more radical.
relay-ctrl is probably the best package as it is only a few files. It basically provides pop before smtp for qmail.
If I do start-stop-daemon --start --exec ${PRERUN} \ /usr/lib/courier-imap/couriertcpd \ --pidfile "${PIDFILE}" -- \ -address="${ADDRESS}" \ -stderrlogger=/usr/lib/courier-imap/courierlogger \ -stderrloggername=imapd \ -maxprocs="${MAXDAEMONS}" -maxperip="${MAXPERIP}" \ -pid="${PIDFILE}" ${TCPDOPTS} \ "${PORT}" /usr/sbin/imaplogin \ /usr/sbin/courier-imapd "${MAILDIR}" it will fail, however strace -o /dev/null start-stop-daemon --start --exec ${PRERUN} \ /usr/lib/courier-imap/couriertcpd \ --pidfile "${PIDFILE}" -- \ -address="${ADDRESS}" \ -stderrlogger=/usr/lib/courier-imap/courierlogger \ -stderrloggername=imapd \ -maxprocs="${MAXDAEMONS}" -maxperip="${MAXPERIP}" \ -pid="${PIDFILE}" ${TCPDOPTS} \ "${PORT}" /usr/sbin/imaplogin \ /usr/sbin/courier-imapd "${MAILDIR}" works
Also, I have edited prerun to have the whole path for all executables, however strace seems to set the PATH.
Created attachment 65045 [details] /lib/rcscript/sh/rc-daemon.sh New rc-daemon.sh. Put it in /lib/rcscripts/sh
Created attachment 65046 [details] courier-imapd Please test this courier-imap with PRERUN If it works, then I'll redo the others
Created attachment 65050 [details] rc-daemon.sh Fixed a stopping flaw
One last thing. For this to work, PREUN needs to call fully pathed entities like so PRERUN="/usr/bin/envdir /etc/relay-ctrl /usr/bin/relay-ctrl-chdir"
Courier-imap 4.0.4 seems to fix it
Bah, it's back to the old way of doing it with the /usr/lib/courier-imap/gentoo-imapd.rc kludge
*** Bug 102370 has been marked as a duplicate of this bug. ***
I can verify that this is still a problem with the new 1.12.0_pre6 version of baselayout: # /etc/init.d/courier-authlib start * Starting courier-authlib: authdaemond ... pidof: invalid options on command line! [ !! ] This is with the following package versions: sys-apps/baselayout-1.12.0_pre6 net-libs/courier-authlib-0.57 net-mail/courier-imap-4.0.4 Looks like someone also filed Bug 103014 which is related to this.
I should probably also note that I'm testing on an amd64/em64t machine and so my rc-daemon.sh is in /lib64/rcscripts/sh. Apart from courier-authlib still not starting up, the only real differences that I can see (other than the use of extra double-quotes in my 1.12.0_pre6 version and minor whitespace differences) between your attached rc-daemon.sh (id 65050) and the rc-daemon.sh in my baselayout-1.12.0_pre6 is this: 65,67d64 < --pid=*) < pidfile="${1##--pid=}" < ;; 267c264 < if [[ -f ${pidfile} ]]; then --- > if [[ -s ${pidfile} ]]; then Note that the difference appears to be related to your having "Fixed a stopping flaw" in your attachment id 65050 vs the one in id 65045, meaning that my current rc-daemon.sh is closer to you older revision. courier-authlib does not seem to start regardless of which I try.
I don't know if the "real" problem lies with the courier-authlib init script in net-libs/courier-authlib-0.57 or the rc-daemon.sh in sys-apps/baselayout-1.12.0_pre6, but I do know that the "quick fix" for rc-daemon.sh from the reporter of Bug 103014 seems to work fine, allowing the authdaemond to start properly. I do not know however if that hack will cause any side-effects for other init scripts.
My "quick fix" should not affect any init scripts that used to work before. It affects only those whose command line parameters start with a minus sign and those will not work with the original rc-daemon.sh anyway. However some caution is required because in case when one of the broken scripts has a command line with a parameter that happens to be a name of some process unrelated to the daemon being started then its PID will be fetched and the process will be killed. This is not the case with authdaemon but may happen with some other scripts. So if you have an init script that does not work and you want to try my fix please look into /etc/init.d first and see what the actual command line parameters are. I feel that a better method of searching for the relevant PIDs is needed because an accidental killing of an unrelated process may occur no matter if the rc-daemon.sh contains my hack or not.
(In reply to comment #38) > I feel that a better method of searching for the relevant PIDs > is needed because an accidental killing of an unrelated process may occur no > matter if the rc-daemon.sh contains my hack or not. I agree with your analysis. I think the ideal solution would involve a more robust method of determining the PIDs, since currently there is definitely potential for things to go wrong with or without the hack.
I'm currently using baselayout-1.12.0_pre8-r2. I had to restart the courier imap/pop/imaps/pops daemons today and lo and behold they didn't restart with the recent baselayout update. Everything else in my tree is stable, but we use an unstable baselayout here at work so we can get the advantage of the new network scripts which we need from tun/tap/bridging. I tried playing around with the init script, but rather than use any of the suggestions on this page, since this is a work enviroment and e-mail downtime means my head, I just started everything manually (authlib, gentoo-imap.rc, etc) I'm requesting that if any changes are made to the init scripts, that they be tested with both the stable and unstable bayselayout and be back ported to the stable tree for peeps like me who are in stable with an unstable baselayout.
It almost sounds like you are asking for QA.... But seriously, ~x86 means unstable/testing. That is our QA. These recent baselayout changes have been pretty hard on everyone. (In fact, all my servers at work, which I stupidly made ~x86 thinking I could keep with the changes, are being converted away from Gentoo because of the recent string of breakage due to these big changes). In the long run Gentoo will be better for it. People just have to bear with us as we make the transition.
are these scripts for use with courier-imap 3.0.8 or do they need 4.0.1 ??
In theory, they should work with courier-* 3 & 4 and with all baselayout versions.
I am currently using Gentoo stable (x86) except for a few apps which I need unstable including the baselayout (mainly to get the extra functionality of /etc/conf.d/net since we do bridging/VPN/other stuff here). I just went up to baselayout-1.12.0_pre9 last night and courier no long starts up correctly via the init scripts. Only authdaemon works, I have to start pop, pop-ssl, imap and imap-ssl manuall by using /usr/lib/courier-imap/gentoo-*.rc This was working before and according to /var/log/emerge.log, the last version I had was baselayout-1.11.13-r1.
courier-imap-4.0.4 has fixed scripts. Not the ones here, but it should work now.
(In reply to comment #45) > courier-imap-4.0.4 has fixed scripts. > > Not the ones here, but it should work now. I wish,...unfortunately the new unstable 4.0.4 STILL doesn't work with baselayout 1.12.0_pre11-r3
*** Bug 129712 has been marked as a duplicate of this bug. ***
Reopen. Someone please finally fix the thing for both stable and unstable, ktnxbye. Almost 50 comments, 9 months and bunch of working fixes attached here later and people still filing bugs and nothing's changed in the scripts... :/ shell script is not a deamon, don't use start-stop-daemon for the thing.
*** Bug 128338 has been marked as a duplicate of this bug. ***
I just wanted to mention that I encountered this same problem as well. Using the attachment for the fixed courier-pop3d-ssl fixed my problem. courier-authlib seems to work fine so I haven't touched that. baselayout: 1.12.0_pre19-r2 courier-authlib: 0.58 courier-imap: 4.0.1
(In reply to comment #50) > I just wanted to mention that I encountered this same problem as well. Using > the attachment for the fixed courier-pop3d-ssl fixed my problem. > courier-authlib seems to work fine so I haven't touched that. > > baselayout: 1.12.0_pre19-r2 > courier-authlib: 0.58 > courier-imap: 4.0.1 I too bumped into it just today. My case was courier-imapd-ssl with baselayout-1.12.
A followup to this. As I've maintained all along, all of courier-imap works perfectly fine for me, and has always done so. I've just double checked after updating to make even more sure. baselayout-1.12.1 and courier-imap-4.0.4 Proof: # ps -ef |grep imapd-ssl ; /etc/init.d/courier-imapd-ssl start; echo ; ps -ef |grep imapd-ssl root 27165 24511 0 15:02 pts/0 00:00:00 grep imapd-ssl * Starting courier-imapd over SSL ... [ ok ] root 27223 1 0 15:02 ? 00:00:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/lib/courier-imap/courierlogger -stderrloggername=imapd-ssl -maxprocs=40 -maxperip=16 -pid=/var/run/imapd-ssl.pid -nodnslookup -noidentlookup 993 /usr/sbin/couriertls -server -tcpd /usr/sbin/imaplogin /usr/lib/courier-imap/courier-imapd.indirect .maildir root 27228 1 0 15:02 ? 00:00:00 /usr/lib/courier-imap/courierlogger imapd-ssl root 27233 24511 0 15:02 pts/0 00:00:00 grep imapd-ssl # ps -ef |grep imapd-ssl ; /etc/init.d/courier-imapd-ssl stop; echo ; ps -ef |grep imapd-ssl root 27223 1 0 15:02 ? 00:00:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/lib/courier-imap/courierlogger -stderrloggername=imapd-ssl -maxprocs=40 -maxperip=16 -pid=/var/run/imapd-ssl.pid -nodnslookup -noidentlookup 993 /usr/sbin/couriertls -server -tcpd /usr/sbin/imaplogin /usr/lib/courier-imap/courier-imapd.indirect .maildir root 27228 1 0 15:02 ? 00:00:00 /usr/lib/courier-imap/courierlogger imapd-ssl root 1323 24511 0 15:13 pts/0 00:00:00 grep imapd-ssl * Stopping courier-imapd over SSL ... [ ok ] root 1437 24511 0 15:13 pts/0 00:00:00 grep imapd-ssl
I hope it is here the right bug for my complains. After a upgrade to the new stable baselyout-1.12.4-r2 i can't start /etc/init.d/courier-imapd any more. I get no segnificant error message, only the message that the service failed to start. I use the stable version courier-imap-4.0.1. The messageges: platon ~ # /etc/init.d/courier-imapd start * Service courier-imapd starting * Starting courier-imapd ... * ERROR: courier-imapd failed to start By the way, /etc/init.d/courier-authlib (version 0.58) starts like expected without problems. Till the upgrade to baselayout-1.12.4-r2 everything worked fine. Now are both ebuilds marked as stable and it seems that they don't fit together. Should i open a new bug considering the different baselayout version in the summary of this bug? If not, this bug should be reopened.
(In reply to comment #53) > I use the stable version courier-imap-4.0.1. As said above multiple times, it's fixed in >=4.0.4. Some for heaven's sake finally stabilize a _working_ version, please. Ktnxbye. REOPEN.
*** Bug 143741 has been marked as a duplicate of this bug. ***
*** Bug 143791 has been marked as a duplicate of this bug. ***
*** Bug 143826 has been marked as a duplicate of this bug. ***
jakub: bug 143830 is the stable marking bug for courier-imap-4.0.4 now.
(In reply to comment #58) > jakub: bug 143830 is the stable marking bug for courier-imap-4.0.4 now. Yay! *plop* ;)
*** Bug 143861 has been marked as a duplicate of this bug. ***
also failed for me with: sys-apps/baselayout-1.12.4-r3
After all this long time, baselayout has been marked stable with courier-imap >4.0.1 still keyworded. So now everyone that keeps their box updated that has tried to stay with the stable packages (like me) has suddenly run into this bug.
People, please stop producing useless noise here. See Bug 143830 for stabilization and use 4.0.4.
*** Bug 144051 has been marked as a duplicate of this bug. ***
*** Bug 144074 has been marked as a duplicate of this bug. ***
4.0.4 stable now, closing.
