|
Bugzilla – Full Text Bug Listing |
| Summary: | Memcached server does not start after upgrading to latest updates | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Vaibhav Kaushal <vaibhavkaushal123> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED INVALID | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | mrueckert, ncutler |
| Version: | Current | ||
| Target Milestone: | Current | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 12.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Vaibhav Kaushal
2013-04-14 05:47:43 UTC
memcach+ 5220 0.0 0.0 317080 872 ? Ssl 10:26 0:00 /usr/sbin/memcached -d -d -l 127.0.0.1 i doubt the extra "-d" is your problem. export SYSTEMD_NO_WRAP=1 and it works for me. the problem is the systemd unit that someone added. that seems to trip over the "-d" in the params options. Christian you introduced the memcached.service file. zypper in memcached
Updating /etc/sysconfig/memcached...
➜ ~ systemctl start memcached
➜ ~ systemctl status memcached
memcached.service - memcached daemon
Loaded: loaded (/usr/lib/systemd/system/memcached.service; disabled)
Active: active (running) since lun 2013-04-22 13:51:37 CLST; 5s ago
Main PID: 11599 (memcached)
CGroup: name=systemd:/system/memcached.service
└─11599 /usr/sbin/memcached -l 127.0.0.1
--> MEMCACHED_PARAMS="-d -l 127.0.0.1" that 's wrong, you upgraded from a previous version and /etc/sysconfig/memcached did not got updated.
MEMCACHED_PARAMS now defaults to "-l 127.0.0.1" as it should..
You must not use "-d", that would require a different time of systemd unit, one of type forking..
I can understand that I need to make the changes and that -d should not be there. However, the point is - whoever made the update patch should have checked. No, I am not whiling like a little baby. I too am an OSS contributor to a PHP framework project and I know that it is not always possible, still this is an 'OS' so... I hope you understand. Anyways, is there a chance that the files will be getting updated in any upcoming patch? (I have made changes anyways, so I am off the worry shelf; just asking). (In reply to comment #3) > I can understand that I need to make the changes and that -d should not be > there. However, the point is - whoever made the update patch should have > checked. I did check it, in fact the files for a new install will work just fine.. but this sysconfig stuff does not have a programatic way to merge user changes in a particular sysconfig variable without removing all user modifications to that variable and creating it again from the start. > Anyways, is there a chance that the files will be getting updated in any > upcoming patch? (I have made changes anyways, so I am off the worry shelf; just > asking). See above, this stuff is absolutely retarded and should have been obsoleted long time ago by the particular daemon own 's configuration file. (In reply to comment #3) > I can understand that I need to make the changes and that -d should not be > there. However, the point is - whoever made the update patch should have > checked. did it create an memcached*rpmnew file in /etc/sysconfig/ on upgrade ? No it did not. (In reply to comment #6) > No it did not. Which illustrates my point.. Moving to Tumbleweed and setting needinfo on assignee for an update. What is the current status? We are not going to spend any time for an ancient openSUSE 12.3 bug from 2013, much less with somebody just dumping it on us without any comment. Also, this is almost certainly not a YaST bug. This is not the Wild West where you have to constantly prove your innocence. BTW in general, whenever the user upgrades a package to a newer version, and then it doesn't work anymore, it's the problem of that package, not of the installer (YaST or zypper): The package needs to do whatever is necessary to make it work in its pre- or post-install scripts which are also called during package upgrade. It might not be the Wild West, but we've got tumbleweed! Anyway, if this is assigned to YaST then it matches this: https://confluence.suse.com/display/YAST/How+to+Write+a+Good+Bug+Report (sorry internal only) What Makes Bug Report a Bad Bug Report - Don't report wrong content of repositories, package conflicts, incorrectly built media, errors or timeout of some commandline tools, etc. as Installer/YaST bug. Use something that fits better or just Other. |