Bug#868150: imapproxy: fails to start
Quack, On 08/08/2017 02:12 PM, Richard Laager wrote: > I have prepared the changes and submitted the required bug for > stable-proposed-updates here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871451 > > I assume I need to hear some sort of ACK on that bug before I (ask my > sponsor to) upload. I was in DebConf in Canada and going back home tomorrow. I cannot build for stable now and check your patch, but will be able to do so at the end of the week. \_o< signature.asc Description: OpenPGP digital signature
Bug#868150: imapproxy: fails to start
On 07/18/2017 01:28 PM, Richard Laager wrote: > Agreed on stable-proposed-updates. I plan to prepare an upload in the next > few days. I have prepared the changes and submitted the required bug for stable-proposed-updates here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871451 I assume I need to hear some sort of ACK on that bug before I (ask my sponsor to) upload. -- Richard
Bug#868150: imapproxy: fails to start
Agreed on stable-proposed-updates. I plan to prepare an upload in the next few days. -- Richard
Bug#868150: imapproxy: fails to start
Quack, On 2017-07-16 16:00, Richard Laager wrote: From my first testing, it worked fine without PIDFile. Unfortunately, upon further testing, it seems to fail most of the time. Given that those errors seem harmless, I think setting PIDFile is the lesser of the two evils right now, so I'm sticking with that. I've sent the update to my sponsor. (I'm not a DD.) I've never configured a Type=forking service, so I guess I lack some knowledge. Looks like a race condition but I'm not sure. I should probably explore the idea of adding a command-line option to imapproxy that sets foreground_mode. Then, I can use that in the systemd unit, making this Type=simple instead of Type=forking. That could be useful anyway for debugging, so I think it's a good idea. Thanks for your upload :-). Nevertheless it doe not solve my problem yet because my service is on stable. I think it's important enough to ask for an upload to stable-proposed-updates. Please look at the procedure before uploading. \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
With PIDFile=/run/imapproxy.pid, I get the following errors: PID file /run/imapproxy.pid not readable (yet?) after start: No such file or directory Supervising process 824 which is not our child. We'll most likely not notice when it exits. >From my first testing, it worked fine without PIDFile. Unfortunately, upon further testing, it seems to fail most of the time. Given that those errors seem harmless, I think setting PIDFile is the lesser of the two evils right now, so I'm sticking with that. I've sent the update to my sponsor. (I'm not a DD.) I should probably explore the idea of adding a command-line option to imapproxy that sets foreground_mode. Then, I can use that in the systemd unit, making this Type=simple instead of Type=forking. -- Richard
Bug#868150: imapproxy: fails to start
On 2017-07-14 12:56, Richard Laager wrote: Is the PIDFile line actually necessary for you? Can you re-test without the PIDFile line in the service? « There is indeed not [Install] section. If I add one with "WantedBy=multi-user.target" I can enable the service but still it does not start properly. » So no. I added it because I looked at the service configuration differences with other similar forking daemons and this was the only obvious one. With it everything works well without warning here. With that line, I get additional errors/warnings. Without it, systemd is still able to detect the main PID of the process. Could you paste the relevant logs? \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
Is the PIDFile line actually necessary for you? Can you re-test without the PIDFile line in the service? With that line, I get additional errors/warnings. Without it, systemd is still able to detect the main PID of the process. On 07/13/2017 02:52 AM, Marc Dequènes (duck) wrote: > So better would be to change the path where the pidfile is created, but > you can do this when you have time. Sure, that's trivial. I have that change ready. > Search the word "Thanks" in /usr/share/doc/dpkg/changelog.Debian.gz for > plenty of examples. gbp-dch supports a Thanks meta tag, which has this result, so that seems like the correct answer. > Also please use "Marc Dequènes (Duck)". Noted and done. -- Richard
Bug#868150: imapproxy: fails to start
Quack, On 2017-07-13 14:40, Richard Laager wrote: Does it still work for you with /var/run instead of /run? Please use /run, it's officially in use and the goal is to transition *to* it: https://wiki.debian.org/ReleaseGoals/RunDirectory So better would be to change the path where the pidfile is created, but you can do this when you have time. [ Marc Dequènes ] * Correct the service file (Closes: 868150) This notation is used when multiple co-maintainers contribute to the save version. Or I can let the git author default to me and just credit you textually in the commit message. Search the word "Thanks" in /usr/share/doc/dpkg/changelog.Debian.gz for plenty of examples. Also please use "Marc Dequènes (Duck)". Do you have a preference? Are you okay with "Correct the service file" or would you like to provide your own commit message for that patch? That's fine. Thanks for your prompt reply :-). \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
On 07/12/2017 08:00 AM, Marc Dequènes (duck) wrote: > --- imapproxy.service.orig 2017-07-12 14:57:35.0 +0200 > +++ /lib/systemd/system/imapproxy.service 2017-07-12 > 14:50:15.0 +0200 > @@ -8,3 +8,8 @@ > Type=forking > ExecStartPre=/usr/share/imapproxy/prepare-chroot > ExecStart=/usr/sbin/imapproxyd -f /etc/imapproxy.conf > +PIDFile=/run/imapproxy.pid > + > +[Install] > +WantedBy=multi-user.target > + imapproxyd actually writes the PID file to /var/run/imapproxy.pid (by default). With /var/run being a symlink to /run, these should be equivalent. It seems slightly more correct to me to use: PIDFile=/var/run/imapproxy.pid Does it still work for you with /var/run instead of /run? I'm not sure on the normal etiquette for crediting in debian/changelog. I'd like to credit you for the patch. The obvious way to do so is to mark you as the git author, but then I'm writing a commit message that has your name attached, which feels weird. So I can either do that, so this happens in debian/changelog: [ Marc Dequènes ] * Correct the service file (Closes: 868150) Or I can let the git author default to me and just credit you textually in the commit message. Do you have a preference? Are you okay with "Correct the service file" or would you like to provide your own commit message for that patch? -- Richard
Bug#868150: imapproxy: fails to start
Package: imapproxy Version: 1.2.8~svn20161210-2 Severity: grave Quack, The server does not start. Trying to restart it does not change anything. Here is the systemd status: # systemctl status imapproxy ● imapproxy.service - IMAP proxy Loaded: loaded (/lib/systemd/system/imapproxy.service; static; vendor preset: enabled) Active: inactive (dead) Docs: man:imapproxyd(8) Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: main(): Internal admin commands are disabled Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: main(): Allocating 3072 IMAP connection structures. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: main(): Enabling openssl library. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: Initialising 1 pthread_mutexes Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ServerInit(): Using '/var/log/imapproxy_protocol.log' for global protocol logging file. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ServerInit(): proxying to IMAP server 'localhost'. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ServerInit(): Proxying to IMAP port 143 Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ParseBannerAndCapability: Attempting to parse capability string: * OK [CAPABILITY IMAP4rev1 LITERAL+ SA Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: [238B blob data] Jul 12 14:32:49 Orfeo systemd[1]: Started IMAP proxy. The service is marked as "static", which is wrong in this case IIUC. Interestingly: # systemctl enable imapproxy Synchronizing state of imapproxy.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable imapproxy The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. There is indeed not [Install] section. If I add one with "WantedBy=multi-user.target" I can enable the service but still it does not start properly. But if I use the init script directly it starts fine (and the service works fine too, so the config is all right): # /etc/init.d/imapproxy start Starting imapproxy (via systemctl): imapproxy.service. # /etc/init.d/imapproxy status ● imapproxy.service - IMAP proxy Loaded: loaded (/lib/systemd/system/imapproxy.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2017-07-12 14:40:25 CEST; 2min 37s ago Docs: man:imapproxyd(8) Process: 19772 ExecStart=/usr/sbin/imapproxyd -f /etc/imapproxy.conf (code=exited, status=0/SUCCESS) Process: 19766 ExecStartPre=/usr/share/imapproxy/prepare-chroot (code=exited, status=0/SUCCESS) Main PID: 19776 (imapproxyd) Tasks: 2 (limit: 4915) Memory: 1.6M CPU: 19ms CGroup: /system.slice/imapproxy.service └─19776 /usr/sbin/imapproxyd -f /etc/imapproxy.conf Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: ServerInit(): proxying to IMAP server 'localhost'. Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: ServerInit(): Proxying to IMAP port 143 Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: ParseBannerAndCapability: Attempting to parse capability string: * OK [CAPABILITY IMAP4rev1 …cot ready. Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: [238B blob data] Jul 12 14:40:25 Orfeo systemd[1]: Started IMAP proxy. Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: BecomeNonRoot(): Process will run as uid 65534 (nobody) and gid 65534 (nogroup). Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: BecomeNonRoot(): Process chrooted in /var/lib/imapproxy/chroot Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: BecomeNonRoot(): enabled no_new_privs Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: main(): Launched ICC recycle thread with id 140509281154816 Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: main(): imapproxy version 1.2.8 [SVN] normal server startup. Hint: Some lines were ellipsized, use -l to show in full. In the end, with the following patch it works fine: --- imapproxy.service.orig
