You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Reindl Harald <h....@thelounge.net> on 2013/08/09 10:58:07 UTC

host database broken

i am pretty sure that "3.3.5-dev" has the same problem as currently 3.2.5
and that is the cause for "Unable to locate the server named"

-rw-r--r-- 1 ats ats 12M 2013-08-09 10:51 /var/cache/trafficserver/host.db

* if i delete this file and start TS it get's generated
* but it never works
* the errors below are at every restart
* 3.3.5-dev just don't log it

if i pull "/var/cache/trafficserver/host.db" from a working host
with 3.2.x with the same config it works

why can this thing not be disabled at all and normal DNS requests/memory
caching be done like in any other application?
_______________________________________________

[Aug  9 10:50:09.899] Server {0x2aaaaaeae9c0} NOTE: cache clustering disabled
[Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} WARNING: header missing/corrupt: [hostdb.config] : reinitializing
database
[Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} NOTE: reconfiguring host database
[Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} WARNING: header missing/corrupt: [hostdb.config] : disabling database
You may need to 'reconfigure' your cache manually.  Please refer to
the 'Configuration' chapter in the manual



Re: host database broken

Posted by Eddie <zt...@yahoo.com>.





________________________________
 From: Leif Hedstrom <zw...@apache.org>
To: users@trafficserver.apache.org 
Sent: Friday, August 9, 2013 5:41 PM
Subject: Re: host database broken
 

On Aug 9, 2013, at 3:32 PM, James Peach <jp...@apache.org> wrote:

> On Aug 9, 2013, at 1:44 PM, Reindl Harald <h....@thelounge.net> wrote:
> 
>> 
>> 
>> Am 09.08.2013 19:37, schrieb Alan M. Carroll:
>> 
>> /etc/ is *readonly*
>> *period*
>> 
>> yes, i know that TS complains about read-only filesystem
>> that is a bug and should be fixed
>> 
>> *any* service which *writes* in /etc is broken
>> *period*
>> 
>> services has to store their dynamic data in /var/lib/servicename
>> and/or /varcache/servicename and not elsewhere
> 
> Yes, I agree that this behaviour can be undesirable. Maybe it's better for your environment to configure trafficserver with --sysconfdir=/var/lib/trafficserver.
> 
> If you file a bug, we can look into altering the default behaviour but it's likely to be a difficult task.

There is

    https://issues.apache.org/jira/browse/TS-203
    https://issues.apache.org/jira/browse/TS-315


-- Leif

Re: Traffic server to origin server connection

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 7:30 AM, Eddie <zt...@yahoo.com> wrote:

> HI,
> 
> In following link, http://trafficserver.apache.org/docs/trunk/admin/reverse-proxy-http-redirects/index.en.html
> I saw this statement and curious how to configure it and what it is used for?
> 
> Traffic Server opens an HTTP connection to the origin server. (This step is optional)
> 
> Could someone please explain a little bit?
> 
> Thanks
> 
> Eddie
> 


A guess would be that they meant for 3) to be optional if 4) kicks in (serving out of cache). It will not create (or acquire from session pool) a connection to the origin if the request can be satisfied entirely out of cache.

-- Leif


Traffic server to origin server connection

Posted by Eddie <zt...@yahoo.com>.
HI,

In following link, http://trafficserver.apache.org/docs/trunk/admin/reverse-proxy-http-redirects/index.en.html
I saw this statement and curious how to configure it and what it is used for?

	1. Traffic Server opens an HTTP connection to the origin server. (This step is optional)

Could someone please explain a little bit?

Thanks

Eddie

Re: host database broken

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 9, 2013, at 3:32 PM, James Peach <jp...@apache.org> wrote:

> On Aug 9, 2013, at 1:44 PM, Reindl Harald <h....@thelounge.net> wrote:
> 
>> 
>> 
>> Am 09.08.2013 19:37, schrieb Alan M. Carroll:
>> 
>> /etc/ is *readonly*
>> *period*
>> 
>> yes, i know that TS complains about read-only filesystem
>> that is a bug and should be fixed
>> 
>> *any* service which *writes* in /etc is broken
>> *period*
>> 
>> services has to store their dynamic data in /var/lib/servicename
>> and/or /varcache/servicename and not elsewhere
> 
> Yes, I agree that this behaviour can be undesirable. Maybe it's better for your environment to configure trafficserver with --sysconfdir=/var/lib/trafficserver.
> 
> If you file a bug, we can look into altering the default behaviour but it's likely to be a difficult task.

There is

	https://issues.apache.org/jira/browse/TS-203
	https://issues.apache.org/jira/browse/TS-315


-- Leif


Re: host database broken

Posted by Leif Hedstrom <zw...@apache.org>.
[The ASF mail filters marked my reply as spam, so trying again with the quoted email removed].

We're weak in this area, but, you can probably use the parent.config for this.

-- Leif


Re: host database broken

Posted by Ocean <oc...@vip.qq.com>.
hi all:
   I have a question in hostdb. In my use circumstance I have two origin server, one used as master ,and the other as backup, I want all ats back to the master first if it worked normal, if the master  is down , all should be to the backup. 
   I configured my dns with fixed order but not round robin,that is to say, the dns result is fixed order.for example:
   www.example.com 192.168.1.1
   www.example.com 192.168.1.2
If I use dig command , the dns  return the results in this order all the time.
   but ats has a DNS resolver itself , I didn't know how it works. In my test, I  found that ats choose the ip which has greater value, although I put the the greater value ip in second place, in www.example.com ,  ats always choose 192.168.1.2 first.
     Can anybody tell me wether my guess is right?  and how can I let ats choose  the first ip in priority? 


------------------ Original ------------------
From:  "zwoop"<zw...@apache.org>;
Date:  Sat, Aug 10, 2013 07:14 AM
To:  "users"<us...@trafficserver.apache.org>; 

Subject:  Re: host database broken



On Aug 9, 2013, at 4:55 PM, Reindl Harald <h....@thelounge.net> wrote:

> 
> Am 10.08.2013 00:43, schrieb Leif Hedstrom:
>> On Aug 9, 2013, at 4:39 PM, Reindl Harald <h....@thelounge.net> wrote:
>>> if it would be placed in /var/cache/trafficserver instead of /etc/trafficserver/internal
>>> all would be fine - the point is that for security reasons no server process should
>>> need mandatory write access for /etc, not more and not less and for non-clustered
>>> all the messages below could go away easily
>> 
>> sounds good, file a bug and attach a patch :). It'd be a simple change I think, and now that 
>> we've started v3.5.x development, it's ok to break compatibility
> 
> well, if i would be a C-programmer you already would have a patch as well as
> i would investigate what is eating CPU load all the long in idle-state which
> results in around 150 MHz idle-load

well, if you submit a bug in Jira, I'll fix the hostdb.config directory.

-- leif

.

Re: host database broken

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 9, 2013, at 4:55 PM, Reindl Harald <h....@thelounge.net> wrote:

> 
> Am 10.08.2013 00:43, schrieb Leif Hedstrom:
>> On Aug 9, 2013, at 4:39 PM, Reindl Harald <h....@thelounge.net> wrote:
>>> if it would be placed in /var/cache/trafficserver instead of /etc/trafficserver/internal
>>> all would be fine - the point is that for security reasons no server process should
>>> need mandatory write access for /etc, not more and not less and for non-clustered
>>> all the messages below could go away easily
>> 
>> sounds good, file a bug and attach a patch :). It'd be a simple change I think, and now that 
>> we've started v3.5.x development, it's ok to break compatibility
> 
> well, if i would be a C-programmer you already would have a patch as well as
> i would investigate what is eating CPU load all the long in idle-state which
> results in around 150 MHz idle-load

well, if you submit a bug in Jira, I'll fix the hostdb.config directory.

-- leif


Re: host database broken

Posted by Reindl Harald <h....@thelounge.net>.
Am 10.08.2013 00:43, schrieb Leif Hedstrom:
> On Aug 9, 2013, at 4:39 PM, Reindl Harald <h....@thelounge.net> wrote:
>> if it would be placed in /var/cache/trafficserver instead of /etc/trafficserver/internal
>> all would be fine - the point is that for security reasons no server process should
>> need mandatory write access for /etc, not more and not less and for non-clustered
>> all the messages below could go away easily
> 
> sounds good, file a bug and attach a patch :). It'd be a simple change I think, and now that 
> we've started v3.5.x development, it's ok to break compatibility

well, if i would be a C-programmer you already would have a patch as well as
i would investigate what is eating CPU load all the long in idle-state which
results in around 150 MHz idle-load

on a VMware host with having on each guest one application doing this you end up
easily in 4-5 GHz where you otherwise have 500-700 Mhz for 15 guests with one ATS

unfortunately i am PHP/MySQL developer and sysadmin with RPM-package skills :-(


Re: host database broken

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 9, 2013, at 4:39 PM, Reindl Harald <h....@thelounge.net> wrote:

> 
> Am 10.08.2013 00:34, schrieb Leif Hedstrom:
>> On Aug 9, 2013, at 4:01 PM, Reindl Harald <h....@thelounge.net> wrote:
>> 
>>>> I believe that the reason ATS does not use the system DNS API is that it is a
>>>> synchronous API and does not support additional records types (eg. SRV records)
>>> 
>>> well, thats reasonable but why is "hostdb.config" needed at file if it can
>>> and should be commpletly removed after upgrades and is generated dynamically
>>> at startup?
>> 
>> You could argue that the hostdb.config info should be stored in the host.db file. But alas, it is not, and it's by design as far as I know (comes from how it repurposed other cache code). Since host.db is persistent, it needs the hostdb.config to function.Basically, it's the only way it knows if you have made changes to records.config that is incompatible with the layout of host.db, and when that happens, it reconfigures both host.db and hostdb.config accordingly.
>> HostDB definitely have (or had) a use case, where caching locally was important for performance (after restart). This is probably no longer true, and I envision HostDB will go away as a persistent cache in v3.6 (replaced with an in-memory cache only).
> 
> if it would be placed in /var/cache/trafficserver instead of /etc/trafficserver/internal
> all would be fine - the point is that for security reasons no server process should
> need mandatory write access for /etc, not more and not less and for non-clustered
> all the messages below could go away easily


sounds good, file a bug and attach a patch :). It'd be a simple change I think, and now that we've started v3.5.x development, it's ok to break compatibility.

-- leif


Re: host database broken

Posted by Reindl Harald <h....@thelounge.net>.
Am 10.08.2013 00:34, schrieb Leif Hedstrom:
> On Aug 9, 2013, at 4:01 PM, Reindl Harald <h....@thelounge.net> wrote:
> 
>>> I believe that the reason ATS does not use the system DNS API is that it is a
>>> synchronous API and does not support additional records types (eg. SRV records)
>>
>> well, thats reasonable but why is "hostdb.config" needed at file if it can
>> and should be commpletly removed after upgrades and is generated dynamically
>> at startup?
> 
> You could argue that the hostdb.config info should be stored in the host.db file. But alas, it is not, and it's by design as far as I know (comes from how it repurposed other cache code). Since host.db is persistent, it needs the hostdb.config to function.Basically, it's the only way it knows if you have made changes to records.config that is incompatible with the layout of host.db, and when that happens, it reconfigures both host.db and hostdb.config accordingly.
> HostDB definitely have (or had) a use case, where caching locally was important for performance (after restart). This is probably no longer true, and I envision HostDB will go away as a persistent cache in v3.6 (replaced with an in-memory cache only).

if it would be placed in /var/cache/trafficserver instead of /etc/trafficserver/internal
all would be fine - the point is that for security reasons no server process should
need mandatory write access for /etc, not more and not less and for non-clustered
all the messages below could go away easily

[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of plugin.config failed: Read-only
file system
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::internalUpdate] Unable to create new version of
plugin.config : Bad file descriptor
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
plugin.config
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of plugin.config failed: Permission
denied
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Config file is read-only : plugin.config
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of splitdns.config failed: Read-only
file system
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::internalUpdate] Unable to create new version of
splitdns.config : Bad file descriptor
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
splitdns.config
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of splitdns.config failed:
Permission denied
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Config file is read-only : splitdns.config
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of ssl_multicert.config failed:
Read-only file system
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::internalUpdate] Unable to create new version of
ssl_multicert.config : Bad file descriptor
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
ssl_multicert.config
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of ssl_multicert.config failed:
Permission denied
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Config file is read-only :
ssl_multicert.config
[Aug 10 00:31:57.259] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of stats.config.xml failed:
Read-only file system
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::internalUpdate] Unable to create new version of
stats.config.xml : Bad file descriptor
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
stats.config.xml
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of stats.config.xml failed:
Permission denied
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Config file is read-only : stats.config.xml
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of prefetch.config failed: Read-only
file system
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::internalUpdate] Unable to create new version of
prefetch.config : Bad file descriptor
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
prefetch.config
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of prefetch.config failed:
Permission denied
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Config file is read-only : prefetch.config
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of cluster.config failed: Read-only
file system
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::internalUpdate] Unable to create new version of
cluster.config : Bad file descriptor
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
cluster.config
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::openFile] Open of cluster.config failed: Permission
denied
[Aug 10 00:31:57.260] Manager {0x7fee28124900} NOTE: [Rollback::Rollback] Config file is read-only : cluster.config


Re: host database broken

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 9, 2013, at 4:01 PM, Reindl Harald <h....@thelounge.net> wrote:

> 
> 
>> I believe that the reason ATS does not use the system DNS API is that it is a
>> synchronous API and does not support additional records types (eg. SRV records)
> 
> well, thats reasonable but why is "hostdb.config" needed at file if it can
> and should be commpletly removed after upgrades and is generated dynamically
> at startup?
> 

You could argue that the hostdb.config info should be stored in the host.db file. But alas, it is not, and it's by design as far as I know (comes from how it repurposed other cache code). Since host.db is persistent, it needs the hostdb.config to function.Basically, it's the only way it knows if you have made changes to records.config that is incompatible with the layout of host.db, and when that happens, it reconfigures both host.db and hostdb.config accordingly.

HostDB definitely have (or had) a use case, where caching locally was important for performance (after restart). This is probably no longer true, and I envision HostDB will go away as a persistent cache in v3.6 (replaced with an in-memory cache only).

Cheers,

-- leif

Re: host database broken

Posted by Reindl Harald <h....@thelounge.net>.

Am 09.08.2013 23:32, schrieb James Peach:
> On Aug 9, 2013, at 1:44 PM, Reindl Harald <h....@thelounge.net> wrote:
>> Am 09.08.2013 19:37, schrieb Alan M. Carroll:
>>> Friday, August 9, 2013, 3:58:07 AM, you wrote:
>>>
>>>> i am pretty sure that "3.3.5-dev" has the same problem as currently 3.2.5
>>>> and that is the cause for "Unable to locate the server named"
>>>
>>> I was able to replicate this issue by changing the user ID of the traffic_server process. There is a hidden file that stores some additional HostDB information and if that can't be written the host.db never gets successfully reconfigured. Once I removed the hidden file and made sure the directory permissions matched the ATS user, the host.db was reconfigured successfully. Removing host.db caused a single start to reconfigure and subsequent restarts had no issue.
>>>
>>> Check the file etc/trafficserver/internal/hostdb.config and the containing directory to see if that is the problem. In particular that both are owned by 'ats' and not 'nobody'. However, when I did this I got a
>> message in diags.log about the permission denied on that file.
>>
>> /etc/ is *readonly*
>> *period*
>>
>> yes, i know that TS complains about read-only filesystem
>> that is a bug and should be fixed
>>
>> *any* service which *writes* in /etc is broken
>> *period*
>>
>> services has to store their dynamic data in /var/lib/servicename
>> and/or /varcache/servicename and not elsewhere
> 
> Yes, I agree that this behaviour can be undesirable. Maybe it's better for your environment to configure trafficserver with --sysconfdir=/var/lib/trafficserver.
> If you file a bug, we can look into altering the default behaviour but it's likely to be a difficult task

--sysconfdir=/var/lib/trafficserver does not help much because the application must
not write in it's configurations and without clustering there is no need to do so

if *all* configurations would go to /var/lib/trafficserver i had to
do ReadOnlyDirectories=/var/lib/trafficserver

the point is that /etc/trafficserver/internal/hostdb.config has to be in
/var/cache/trafficserver/hostdb.config

> I believe that the reason ATS does not use the system DNS API is that it is a
> synchronous API and does not support additional records types (eg. SRV records)

well, thats reasonable but why is "hostdb.config" needed at file if it can
and should be commpletly removed after upgrades and is generated dynamically
at startup?


Re: host database broken

Posted by James Peach <jp...@apache.org>.
On Aug 9, 2013, at 1:44 PM, Reindl Harald <h....@thelounge.net> wrote:

> 
> 
> Am 09.08.2013 19:37, schrieb Alan M. Carroll:
>> Friday, August 9, 2013, 3:58:07 AM, you wrote:
>> 
>>> i am pretty sure that "3.3.5-dev" has the same problem as currently 3.2.5
>>> and that is the cause for "Unable to locate the server named"
>> 
>> I was able to replicate this issue by changing the user ID of the traffic_server process. There is a hidden file that stores some additional HostDB information and if that can't be written the host.db never gets successfully reconfigured. Once I removed the hidden file and made sure the directory permissions matched the ATS user, the host.db was reconfigured successfully. Removing host.db caused a single start to reconfigure and subsequent restarts had no issue.
>> 
>> Check the file etc/trafficserver/internal/hostdb.config and the containing directory to see if that is the problem. In particular that both are owned by 'ats' and not 'nobody'. However, when I did this I got a
> message in diags.log about the permission denied on that file.
> 
> /etc/ is *readonly*
> *period*
> 
> yes, i know that TS complains about read-only filesystem
> that is a bug and should be fixed
> 
> *any* service which *writes* in /etc is broken
> *period*
> 
> services has to store their dynamic data in /var/lib/servicename
> and/or /varcache/servicename and not elsewhere

Yes, I agree that this behaviour can be undesirable. Maybe it's better for your environment to configure trafficserver with --sysconfdir=/var/lib/trafficserver.

If you file a bug, we can look into altering the default behaviour but it's likely to be a difficult task.

> 
>>> -rw-r--r-- 1 ats ats 12M 2013-08-09 10:51 /var/cache/trafficserver/host.db
>> 
>>> * if i delete this file and start TS it get's generated
>>> * but it never works
>>> * the errors below are at every restart
>>> * 3.3.5-dev just don't log it
>> 
>>> if i pull "/var/cache/trafficserver/host.db" from a working host
>>> with 3.2.x with the same config it works
>> 
>>> why can this thing not be disabled at all and normal DNS requests/memory
>>> caching be done like in any other application?

I believe that the reason ATS does not use the system DNS API is that it is a synchronous API and does not support additional records types (eg. SRV records). We would like to clean up (and possibly remove) the HostDB implementation, but currently there is no-one volunteering to do that work, https://cwiki.apache.org/confluence/display/TS/HostDBandDNS.

J

Re: host database broken

Posted by Reindl Harald <h....@thelounge.net>.

Am 09.08.2013 19:37, schrieb Alan M. Carroll:
> Friday, August 9, 2013, 3:58:07 AM, you wrote:
> 
>> i am pretty sure that "3.3.5-dev" has the same problem as currently 3.2.5
>> and that is the cause for "Unable to locate the server named"
> 
> I was able to replicate this issue by changing the user ID of the traffic_server process. There is a hidden file that stores some additional HostDB information and if that can't be written the host.db never gets successfully reconfigured. Once I removed the hidden file and made sure the directory permissions matched the ATS user, the host.db was reconfigured successfully. Removing host.db caused a single start to reconfigure and subsequent restarts had no issue.
> 
> Check the file etc/trafficserver/internal/hostdb.config and the containing directory to see if that is the problem. In particular that both are owned by 'ats' and not 'nobody'. However, when I did this I got a
message in diags.log about the permission denied on that file.

/etc/ is *readonly*
*period*

yes, i know that TS complains about read-only filesystem
that is a bug and should be fixed

*any* service which *writes* in /etc is broken
*period*

services has to store their dynamic data in /var/lib/servicename
and/or /varcache/servicename and not elsewhere

>> -rw-r--r-- 1 ats ats 12M 2013-08-09 10:51 /var/cache/trafficserver/host.db
> 
>> * if i delete this file and start TS it get's generated
>> * but it never works
>> * the errors below are at every restart
>> * 3.3.5-dev just don't log it
> 
>> if i pull "/var/cache/trafficserver/host.db" from a working host
>> with 3.2.x with the same config it works
> 
>> why can this thing not be disabled at all and normal DNS requests/memory
>> caching be done like in any other application?
>> _______________________________________________
> 
>> [Aug  9 10:50:09.899] Server {0x2aaaaaeae9c0} NOTE: cache clustering disabled
>> [Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} WARNING: header missing/corrupt: [hostdb.config] : reinitializing
>> database
>> [Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} NOTE: reconfiguring host database
>> [Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} WARNING: header missing/corrupt: [hostdb.config] : disabling database
>> You may need to 'reconfigure' your cache manually.  Please refer to
>> the 'Configuration' chapter in the manual

-- 

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm


Re: host database broken

Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Friday, August 9, 2013, 3:58:07 AM, you wrote:

> i am pretty sure that "3.3.5-dev" has the same problem as currently 3.2.5
> and that is the cause for "Unable to locate the server named"

I was able to replicate this issue by changing the user ID of the traffic_server process. There is a hidden file that stores some additional HostDB information and if that can't be written the host.db never gets successfully reconfigured. Once I removed the hidden file and made sure the directory permissions matched the ATS user, the host.db was reconfigured successfully. Removing host.db caused a single start to reconfigure and subsequent restarts had no issue.

Check the file etc/trafficserver/internal/hostdb.config and the containing directory to see if that is the problem. In particular that both are owned by 'ats' and not 'nobody'. However, when I did this I got a message in diags.log about the permission denied on that file.


> -rw-r--r-- 1 ats ats 12M 2013-08-09 10:51 /var/cache/trafficserver/host.db

> * if i delete this file and start TS it get's generated
> * but it never works
> * the errors below are at every restart
> * 3.3.5-dev just don't log it

> if i pull "/var/cache/trafficserver/host.db" from a working host
> with 3.2.x with the same config it works

> why can this thing not be disabled at all and normal DNS requests/memory
> caching be done like in any other application?
> _______________________________________________

> [Aug  9 10:50:09.899] Server {0x2aaaaaeae9c0} NOTE: cache clustering disabled
> [Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} WARNING: header missing/corrupt: [hostdb.config] : reinitializing
> database
> [Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} NOTE: reconfiguring host database
> [Aug  9 10:50:09.910] Server {0x2aaaaaeae9c0} WARNING: header missing/corrupt: [hostdb.config] : disabling database
> You may need to 'reconfigure' your cache manually.  Please refer to
> the 'Configuration' chapter in the manual