Description of problem: 121222 10:51:02 [ERROR] mysqld: Can't create/write to file '/var/run/mysqld/mysqld.pid' (Errcode: 2) 121222 10:51:02 [ERROR] Can't start server: can't create PID file: No such file or directory As a result, it also fill the log file Version-Release number of selected component (if applicable): Current Cauldron How reproducible: every time
I have yet to see that problem for Mageia 3 on any phase/release installed on 3 systems. All installs are clean/fresh installs. Running MythTv on my back end system and connecting to mysqld from my front end system. Front end system is also running it's own mysqld service. $ cat /etc/release Mageia release 3 (Cauldron) for x86_64 # systemctl status mysqld mysqld.service - MySQL database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled) Active: active (running) since Fri, 2012-12-21 23:31:22 CST; 13h ago
CC: (none) => junk_no_spam
I can reproduce this. If you start the service as user the error appear. As suoeruser (su) everything will work fine.
CC: (none) => r.wobben
@thonas Spulhler: Did you do the steps as a user or a superuser (su) or root ? Roelof
(In reply to comment #2) > I can reproduce this. I would feel sad if users can manage system services from their account. > If you start the service as user the error appear. Heheh, I can not even do a systemctl status mysqld.service as user like I could on Alpha 1-3.
Keywords: (none) => NEEDINFOCC: (none) => alien
i didn't expect systemctl to be executable as regular user...
(In reply to comment #3) > @thonas Spulhler: > > Did you do the steps as a user or a superuser (su) or root ? > > Roelof As su - and it's also started at the boot process. Teh it fills the logs with the above messages.
Well, I am going to do a fresh install, this was an urpmi upgrade fro maga1 to mga2 and then cauldron. There are a few other things that act up strange.
Fine, Could you report if the problem exist there, so we can investigate it further. Roelof
my first thought was about the /usr merge thing. as iinm mariadb got modified for it. (that also includes /var temp stuff) perhaps your /var tmpfiles thing isn't working correctly?
CC: (none) => mageia
Yeah, check that /var/run is really a symlink to /run on your upgraded machine. Perhaps the /var part of the usrmerge didn't work (if it was done with older mageia-prepare-upgrade package and /var is on a separate partition, then this could theoretically have happened). tmpfiles should have created the directory with the right user and permissions.
Oh and systemctl can be used fine by a regular user. It will only show you things you can already tell from other tools tho' - e.g. it won't show you extracts from the logs (unless you are in the adm group). You can also use systemd as a user session (work is ongoing in his area) and as a result you can use systemctl --user to talk to your user session daemon.
I close this. It didn't surface anymore. It was probably a borked update.
Resolution: (none) => INVALIDStatus: NEW => RESOLVED