Description of problem: systemd[1]: PID file /run/stunnel/stunnel.pid not readable (yet?) after start. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. systemctl start stunnel 2. systemctl status stunnel Workaround: Add pid = /run/stunnel/stunnel.pid to /etc/stunnel/stunnel.conf I bumped Severity to Major since it can effect verizon.net users wanting to use postfix to send email. tried "pid = /usr/var/run/stunnel.pid" per the conf file but it also failed. Someone with systemd service setup experience probably could make that work like it should. Reproducible: Steps to Reproduce:
Thanks, it looks like setting the pid file location as you said in the default config is the correct solution. I have implemented that, as well as disabling SSLv3 in the default config, and submitted a freeze push request.
Summary: 5_rc: /run/stunnel/stunnel.pid not readable => stunnel: /run/stunnel/stunnel.pid not readable
I just finished getting stunnel running on mga4. Same fix, and I had to change chroot = /run/stunnel to ;chroot = /run/stunnel to match mga5 and get it to run.
Changing this bug to Mageia 4 then; stunnel-5.03-4.mga5 is uploaded for Cauldron, mostly fixing this. I don't know if the security issue in Bug 15891 is relevant for Mageia 4.
CC: (none) => guillomovitchVersion: Cauldron => 4Source RPM: stunnel-5.03-3.mga5.src.rpm => stunnel-4.56-3.2.mga4.src.rpm
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Version: 4 => 5
Care to comment Bit Twister? You just changed the version to 5, but comment 3 seems to infer that the bug is fixed in Mageia 5, so more details could be useful.
Whiteboard: (none) => NEEDINFO
> You just changed the version to 5, but comment 3 seems to infer that the bug is > fixed in Mageia 5, Just because it was fixed in Cauldron does not always mean it made it to Official. Worse, the problem showed up in the Release Candidate. That is one of the reasons I put the release_phase: as first word in the subject. You know, the one you always seem to be removing. :( I set it 5 because it is a bug which needs to tested before closing. Now that I verified it works, what Status value should I set. I had set one of my bug reports RESOLVED/FIXED and someone jumped on me indicating QA was the one to do that. So, what value should I set when I verified the problem is resolved?
Status: NEW => ASSIGNEDWhiteboard: NEEDINFO => (none)
I also remove release phase from subjects because it's not an information that is needed in that place. Other people put release phase in the whiteboard, which is recommended. Eg.: 5beta2.
(In reply to Bit Twister from comment #6) > I set it 5 because it is a bug which needs to tested before closing. This is not obvious to people watching notifications, so it's recommended to tell it in a comment at the same time :) > Now that I verified it works, what Status value should I set. > > I had set one of my bug reports RESOLVED/FIXED and someone jumped on me > indicating QA was the one to do that. > > So, what value should I set when I verified the problem is resolved? RESOLVED/FIXED. Only bug reports turned into Update or Backport candidates for a stable release must undergo QA validation, which is a precise process, in which the bug report is closed only when the update has been issued to all users. In other cases, you can and should close bug reports you know are fixed.
(In reply to Bit Twister from comment #6) > Just because it was fixed in Cauldron does not always mean it made it to > Official. > Worse, the problem showed up in the Release Candidate. Well everything that get pushed to Cauldron before the final release does get included in Official. That's why this bug report was set to the Mageia 4 version, as it supposedly did not affect Cauldron/5 after comment 3. > That is one of the reasons I put the release_phase: as first word in the > subject. > You know, the one you always seem to be removing. :( I tend to remove it because it is misleading as it gives the indication that a bug might be present only in whichever release phase it was reported against. I don't want packagers to dismiss a bug report because it's apparently referring to Mageia 2 alpha1... The first occurrence of a bug is still a valuable info, but I don't think personally that it should figure in the bug summary. Others in the bugsquad might not be of this opinion though. > I set it 5 because it is a bug which needs to tested before closing. Thanks, that's the information I was asking for and would have been appropriate to put in a comment. If you only set the version to 5 and then nothing happened on this bug report for 6 months, we would not be closer to its resolution. > Now that I verified it works, what Status value should I set. > > I had set one of my bug reports RESOLVED/FIXED and someone jumped on me > indicating QA was the one to do that. > > So, what value should I set when I verified the problem is resolved? Anyone can mark a bug as RESOLVED FIXED, it's not reserved to the QA team (actually the QA team almost never closes a bug as RESOLVED FIXED, it's done by sysadmins when pushing QA updates). If someone "jump on you", it's probably that you closed as RESOLVED FIXED a bug report that still required an update candidate to be validated, hence it was reopened (and probably set to Mageia N instead of Cauldron, as we do when a bug is fixed in Cauldron but still needs to be fixed in Mageia N). Hope this makes it clearer. At any rate, thanks a lot for your detailed and useful bug reports :)
(In reply to Samuel VERSCHELDE from comment #7,8,9) > I also remove release phase from subjects because it's not an information > that is needed in that place. Other people put release phase in the > whiteboard, which is recommended. Eg.: 5beta2. I assumed whiteboard was Mageia personnel's domain, not really for general public use. > Only bug reports turned into Update or Backport candidates > for a stable release must undergo QA validation, What bug field contains those values? > I don't want packagers to dismiss a bug report because it's apparently > referring to Mageia 2 alpha1... That confuses me. Anytime a bug was assigned to me, it was my job to fix my software if the bug was valid. If not, get with the originator and get a resolution. > Well everything that get pushed to Cauldron before the final release does > get included in Official. That's why this bug report was set to the > Mageia 4 version, as it supposedly did not affect Cauldron/5 after comment 3. Hmmmm, problem opened 5_rc: /run/stunnel/stunnel.pid not readable Maybe, my 5_rc: would have kept it from going back to a working mag4 :) AND, Thank You for your time.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
(In reply to Bit Twister from comment #10) > (In reply to Samuel VERSCHELDE from comment #7,8,9) > > I also remove release phase from subjects because it's not an information > > that is needed in that place. Other people put release phase in the > > whiteboard, which is recommended. Eg.: 5beta2. > > I assumed whiteboard was Mageia personnel's domain, not really for general > public use. Well you probably know that Mageia is a community distro, there is no Mageia personnel :) I see what you mean, but it's mostly a matter of knowing how things work; now that you know how it works, feel free to use it even if you don't considered yourself "certified" to do bug triage. > > Only bug reports turned into Update or Backport candidates > > for a stable release must undergo QA validation, > > What bug field contains those values? Usually when a bug is valid for Cauldron and also stable releases, it's reported against Cauldron, and has whiteboard tags like MGAxTOO where "x" is the release number. You are encouraged to add MGA5TOO yourself if you notice that a Cauldron bug you're reporting is also valid in Mageia 5. So if a bug is fixed in Cauldron and has MGA5TOO, it should not be resolved as FIXED, but the packager should prepare an update candidate, and then change the version to "5" (thus removing the redundant MGA5TOO from the whiteboard) and assign the bug to qa-bugs@ml.mageia.org. > > I don't want packagers to dismiss a bug report because it's apparently > > referring to Mageia 2 alpha1... > > That confuses me. Anytime a bug was assigned to me, it was my job to fix my > software if the bug was valid. If not, get with the originator and get a > resolution. Yes, but checking if a bug is still valid takes time. And we have less developers than fingers, and all have many bugs to handle, so the job of the bug triage team is to make it easy to see at a glance the status of a bug: accurate summary, confirmation of the bug in currently supported releases, etc. > > Well everything that get pushed to Cauldron before the final release does > > get included in Official. That's why this bug report was set to the > > Mageia 4 version, as it supposedly did not affect Cauldron/5 after comment 3. > > Hmmmm, problem opened 5_rc: /run/stunnel/stunnel.pid not readable > Maybe, my 5_rc: would have kept it from going back to a working mag4 :) Well for the problem at hand, David in comment 3 seems to have assumed that there was something to fix in Mageia 4 and no longer in Mageia 5/Cauldron, which is why he changed the version field. It might have been a mistake, I can't really judge as I'm not familiar with this bug.