0

Okay, hopefully I can explain this correctly as I have no idea what's causing this or how to resolve this.

For some reason bash commands (on a CentOS 6.x server) are displaying more information than "normally" and that causes issues with certain scripts. I have no clue if there is a name for this, but hopefully someone knows a solution for this.

First example.

Correct / good server:

[root@goodserver ~]# vzctl enter 3567
entered into CT 3567
[root@example /]#

(this is the correct behaviour)

Incorrect / bad server:

[root@badserver /]# vzctl enter 3127
Entering CT
entered into CT 3127
Open /dev/pts/0
           [root@example /]#

With the "bad" server it will display more information as usual, like:

  • Entering CT
  • Open /dev/pts/0

It's like it parsing extra information on what it's doing.

Ofcourse the above is purely something cosmetic, however with several bash scripts we use, these issues are really issues.

A part of the script we use, uses the following command (there are more, but this is mainly a example of what's wrong):

 DOMAIN=`vzctl exec $VEID 'hostname -d'`

The result of the above information is parsed in /etc/named.conf.

On the GOOD server it would be added in the named.conf like this:

zone "example.com" {
    type master;
    file "example.com";
    allow-transfer {
            200.190.100.10;
            200.190.101.10;
            common-allow-transfer;
    };
};

The above is correct.

On the BAD server it would be added in the named.conf like this:

zone "Executing command: hostname -d
example.com" {
    type master;
    file "Executing command: hostname -d
example.com";
    allow-transfer {
            200.190.100.10;
            200.190.101.10;
            common-allow-transfer;
    };
};

So it's add stuff of the action it does, in this example "Executing command: hostname -d"

Another example here when I run the command on a good server and on the bad server.

Bad server:

[root@bad-server /]# DOMAIN=`vzctl exec 3333 'hostname -d'`
[root@bad-server /]# echo $DOMAIN
Executing command: hostname -d example.com

Good server:

[root@good-server ~]# DOMAIN=`vzctl exec 4444 'hostname -d'`
[root@good-server ~]# echo $DOMAIN
example.com

My knowledge is limited, but I have tried several things checking rsyslog and the grub.conf, but nothing seems out of the ordinary.

I have no clue why it's displaying the extra information.

Probably it's something simple / stupid, but I have been trying to solve this for hours now and I really have no clue...

So any help is really appreciated.

Added information: Both servers use: kernel.printk = 7 4 1 7 (I don't know if that's useful)

Aaron
  • 24,009
  • 2
  • 33
  • 57
Joanne
  • 514
  • 3
  • 8
  • 30
  • I'm not a 100% sure this is going to help you, but you should at least try: `sudo dmesg --console-off` – morgano Feb 08 '18 at 11:40
  • After the command you gave me, I looked into things. However it doesn't help. Both use: kernel.printk = 7 4 1 7 So that's not it.. Thanks though. – Joanne Feb 08 '18 at 11:44
  • 1
    Looking at what I assume is your `vzctl`'s [man](https://openvz.org/Man/vzctl.8) I notice a `--quiet` option that might fix your problem ("Disables output. Note that scripts run by vzctl are still able to produce some output."). So that would be `DOMAIN=$(vzctl --quiet exec $VEID 'hostname -d')` for the second example. For the first example I'm afraid it would disable the "entered into CT 3567" output too though. – Aaron Feb 08 '18 at 11:58
  • Thank for your input, but it still doesn't explain why the script works on every single server, except for this server. Both (good/bad) server use CentOS 6.x so I think it's configured somewhere to put out more information on one server and not the other... I want to know what is causing it and how to disable the (extra) information without adjusting the script in general. – Joanne Feb 08 '18 at 12:09
  • 1
    There must be some server-specific conf that `vzctl` reads. I don't know the tool at all so I won't be able to help further, but I've added the openvz tag to your question in hope it will attract people experienced with the tool. – Aaron Feb 08 '18 at 12:12
  • Aaron thanks! I finally found it (after what you wrote)! In /etc/vz/vz.conf the following was set: VERBOSE=3 I changed that to VERBOSE=0 and re-tested. All the extra nonsense is now gone. I will test it a bit more. But I am sure this it! Thank you for pointing me in the right direction!!! – Joanne Feb 08 '18 at 12:29
  • 1
    Great, you're welcome ! :) If all works well I suggest you post your own answer and accept it. – Aaron Feb 08 '18 at 12:45

2 Answers2

0

Well (thanks to Aaron for pointing me in the right direction) I finally found the little culprit which was causing all the issues I experienced with this script (which worked for every other server, so no need to change that obviously).

The issues were caused by the VERBOSE leven set in vz.conf (located in /etc/vz/ directory). There is an option in there called "VERBOSE" and in my case it was set to 3.

According to OpenVZ's website it does the following:

Increments logging level up from the default. Can be used multiple times. 
Default value is set to the value of VERBOSE parameter in the global
configuration file vz.conf(5), or to 0 if not set by VERBOSE parameter.

After I changed VERBOSE=3 to VERBOSE=0 my script worked fine once again (as it did for every other server). :-)

So a big shoutout to Aaron for pointing me in the right direction. The answer is easy when you know where to look!



Sorry to say, but I am kinda disappointed by ndim's reaction. This is the 2nd time he was very unhelpful and rude in his response after that. He clearly didn't read the issue I posted correctly. Oh well.

Joanne
  • 514
  • 3
  • 8
  • 30
-1

I would make sure to properly parse the output of the command. In this case, we are only interested in lines of the form

entered into CT 12345

One way of doing this would be to pipe everything through sed and having sed print only the number when the line looks as above (untested, and I always forget which braces/brackets/parens need a backslash in front of them):

whateverthecommand | sed -n 's/^entered into CT ([0-9]{1,})$/\1/p'
ndim
  • 35,870
  • 12
  • 47
  • 57
  • Sorry but hasn't anything to do with my issue at all... Not asking for sed command! Both use the exact same script. So sed isn't of any use here at all. I think it's some setting in bash or on the server! – Joanne Feb 08 '18 at 11:54
  • You clearly haven't even read the question / issue correctly. Two servers, both CentOS 6.x, on both server the same script, but different output on both servers when using the same script. The rest in my post are examples. – Joanne Feb 08 '18 at 12:04