Problem with change_username.sh

[azzid]

Hi,

Today I tried to change the name of a user account, but it failed, does anyone recognize my error?

First I ran:

[B]servername:/usr/local/directadmin/scripts#[/B] ./change_username.sh abcdefgh abcdefghij
Starting mysqld:                [ OK ]
Can't open /home/abcdefghij/domains/*/awstats/.data/*.conf: No such file or directory.

The to verify the change:

[B]servername:/usr/local/directadmin/scripts#[/B] ls /home/ | grep abcd
abcdefghij

After that I tried to browse the user homepage but got 404.

So I changed the name back:

[B]servername:/usr/local/directadmin/scripts#[/B] ./change_username.sh abcdefghij abcdefgh
/usr/local/mysql/bin/mysqld_safe: line 137: 17604 Killed                  nohup /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql --log-error=/usr/local/mysql/data/servername.domain.com.err --pid-file=/usr/local/mysql/data/servername.pid < /dev/null >> /usr/local/mysql/data/servername.domain.com.err 2>&1
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Starting mysqld:                [ OK ]
Can't open /home/abcdefgh/domains/*/awstats/.data/*.conf: No such file or directory.

After which the homepage is working.

I would still like to know why the script failed, anyone know?
Also, is it likely that the script has broken something for the user now?

I'm running Debian 5 64-bit and DA 1.38.

 

[nobaloney]

Do you have awstats installed? If so, is it the one supplied with DirectAdmin, or the one created some time ago as a plugin?

Jeff

 

[DirectAdmin Support]

Hello,

I believe the awstats error just means he's not using awstast, since no confs can be found. While checking, I found the awstats.pl wasn't swaped, so that's one bug down anyway (not related to your issue though)

The main error I'm seeing there would be the restart of mysqld.
Check to ensure mysqld is running correctly afterwards.

The script allows 2 seconds for mysqld to shut down before following up with a "killall -9 mysqld" call. I'll change this to 5 seconds for the next release, as I'm guessing that's why the output doesn't look friendly.

It's possible that everything still went ok, as a normal stop is called first, but to ensure it's truly stopped, it's followed up with the "killall -9 mysqld" 2 seconds later. My guess is your system wasn't 100% stopped yet, hence the messages.

Check your databases to ensure they've been renamed.
If they're working ok, you can probably ignore the mysql message.


As for the 404 message, apache needs to be restarted.
This takes up to 1 full minute for the dataskq to find the restart request.

John

 

[azzid]

Do you have awstats installed? If so, is it the one supplied with DirectAdmin, or the one created some time ago as a plugin?

Jeff

Hi Jeff thanks for the reply,

awstats is not installed on the particular server.

Hello,

I believe the awstats error just means he's not using awstast, since no confs can be found. While checking, I found the awstats.pl wasn't swaped, so that's one bug down anyway (not related to your issue though)

The main error I'm seeing there would be the restart of mysqld.
Check to ensure mysqld is running correctly afterwards.

The script allows 2 seconds for mysqld to shut down before following up with a "killall -9 mysqld" call. I'll change this to 5 seconds for the next release, as I'm guessing that's why the output doesn't look friendly.

It's possible that everything still went ok, as a normal stop is called first, but to ensure it's truly stopped, it's followed up with the "killall -9 mysqld" 2 seconds later. My guess is your system wasn't 100% stopped yet, hence the messages.

Check your databases to ensure they've been renamed.
If they're working ok, you can probably ignore the mysql message.


As for the 404 message, apache needs to be restarted.
This takes up to 1 full minute for the dataskq to find the restart request.

John

Hi John thanks for your reply aswell,

As you guessed, there are no awstats on the server.

So the 404 would've gone away by itself if had just given the machine some more time? Got myself a little panic there, hence the swift restore, one day I'll hopefully grow the balls to let things solve themselves.

The line that worries me regarding the mysql restart is:

kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

Seems to me like the script produced malformed input to kill.

Sincerely,
Mattias

 

[nobaloney]

The script allows 2 seconds for mysqld to shut down before following up with a "killall -9 mysqld" call. I'll change this to 5 seconds for the next release, as I'm guessing that's why the output doesn't look friendly.

When I'm working on a server I avoid killall -9 mysqld at all reasonable costs; often trying over and over again with just killall mysqld. Hopefully that keeps from fragmenting the database.

I'm not sure if that's an issue or not, because I don't know what can happen to a database if you force kill mysqld without trying to close all databases.

Do you know?

Jeff