Errors that reveal themselves when working with software products often make it impossible to use them. And the lack of special knowledge to understand the algorithms of work also gives rise to the impossibility of diagnosing and fixing emerging failures. In this article, let's take a look at the problem "Server 1C: Enterprise was not found, how to fix the launch of the agent-server?"
There are several ways to fix the problem in 1C operation.
Errors that arise have different ins and outs, they can be sorted by levels of occurrence:
- Incorrect prescribing of codes by the developers of one-eski itself;
- Errors made by programmers who modify (change) the product in relation to the requirements (tasks) of a particular user;
- Failures caused by errors in the work of the cache memory, which most often baffle programmers;
As for the error "1C: Enterprise server not found", it is unrealistic to attribute it to one of the named ones, since such a notification is an indication to the user not to perform a certain necessary action for the program to work.
We fix it - start the server
So - the situation, which this publication is devoted to, arises when the agent-server service is either disabled or stopped. Note that, as a rule, the reasons for this remain unclear (who is recognized).
This service runs in two ways - either as an application or as a service. Let's see how to do it in both cases:
As an app
To run it as an application, run the command:
In this case, the port, port ranges, level and directory are indicated (in their settings). If these parameters are not specified, then their values will be set by the program "by default".
As a service
When, during the first installation of 1C, the launch option was chosen by the service, then it is registered and subsequently should be launched automatically (at each start of the operating system).
If the agent was originally installed by the application, then you can manually register it and launch it. This will happen on the command (don't forget about the parameters):
ragent.exe -instsrvc -usr ‹specify the name› -pwd ‹specify the password›
Port ‹for port› -regport ‹for port› -range ‹port ranges›
Seclev ‹desired level› -d ‹specifies directory›
The result of registration will be the creation of a new Service (in this case, for 1C version 8.3 for 64-bit):
For memory
To delete (unregister) a service:
Stop:
Now you all know about the causes of the problem "1C: Enterprise server was not detected" and what needs to be done when it appears.
Leave your comments.
It happens, once, for no reason and from what the 1C program gives us: Error connecting to the 1C: Enterprise server Not a single worker process is running. The connection to the base is not possible.
Several options for finding errors and solutions:
1. Server glitch - anything can happen
Stop the processes in the task manager: ragent rphost rmngr and Start the service "Server Agent 1C: Enterprise"
2. In case of a sudden power outage or similar situations - the file is damagedsrvribrg.lst
You need to delete everything from the folder srvinfo
For Windows go to the directory c: \ program files \ 1c \ 1cv82 \srvinfo, if Linux usr1cv8 / home / .1cv8 / 1C / 1cv8 ...
Through the Administration of 1C Enterprise servers, create a new 1C cluster and add infobases
3. Renamed the server on which the 1C agent service
After renaming the Windows Server 2008 server with 1C: Enterprise 8.2 installed, the 1C: Enterprise 8.2 Server Agent service stopped working. It starts up, runs for a few seconds, and then stops. If you connect to the 1C: Enterprise 8.2 server through the server console, an error occurs:
Error connecting to server 1C: Enterprise 8.2 server_addr = tcp: // SERVER: 1540 descr = Error in network access to the server (Windows Sockets - 10061 (0x0000274D). The connection was not established because the destination computer rejected the connection request.) Line = 590 file =. \ Src \ DataExchangeTcpClientItmpl.cpp
When connecting to the database on this server, we have the following error:
No worker process is running. The connection to the base is not possible.
This problem is due to the fact that the settings of the 1C: Enterprise server cluster are stored in files in the srvinfo directory (the path to it is specified by the -d parameter in the properties of the 1C: Enterprise Server Agent service). Therefore, after changing the computer name, you must perform the following additional steps:
For Windows go to the directory c: \ program files \ 1c \ 1cv82 \srvinfo, if Linux- then the files are in the user's home directory on whose behalf the service is launched: usr1cv8 / home / .1cv8 / 1C / 1cv8 ...
Edit two files in any text editor: srvinfo \ srvribrg.lst and srvinfo \ reg_1541 \ 1CV8Reg.lst. Replace the old server name with the new one in these files.
Start the 1C: Enterprise Server Agent service.
After completing the specified actions - Everything will be
if suddenly not - repeat point 2!
The 1C: Enterprise and PostgreSQL server bundle is the second most popular among 1C installations and the most used solution on the Linux platform. Unlike Windows and MSSQL-based deployments, where it is difficult to make things not work, Linux-based deployments are fraught with pitfalls for the inexperienced administrator. It often happens that everything seems to be done correctly, but error follows error. Today we will look at the most typical ones.
general information
Before you start looking for installation errors and, in general, start implementing the server version of 1C: Enterprise, it would be nice to refresh your understanding of how it works:
In small deployments, the 1C server and the DBMS server are usually combined on one physical server, which slightly narrows the range of possible errors. In our case, we will consider the situation when the servers are located on different machines. In our test lab, we deployed the following schema:
We have at our disposal two servers running Ubuntu 12.04 x64, one of them has 1C: Enterprise version 8.3, the other has PostgreSQL 9.04 from Ethersoft, as well as a client running Windows. We remind you that the client is working only with the 1C server, which, in turn, generates the necessary requests to the DBMS server. No requests from the client to the database management server not happening.
IMPORTANT: user "postgres" is not authenticated (Ident)
This error occurs when the servers are spread across different PCs due to incorrectly configured authentication on the local network. To eliminate open /var/lib/pgsql/data/pg_hba.conf, find the line:
Host all all 192.168.31.0/24 ident
and bring it to the form:
Host all all 192.168.31.0/24 md5
where 192.168.31.0/24 - the range of your local network. If there is no such line, it should be created in the section IPv4 local connections.
Database server not found
could not translate host name "NAME" to address: Temporary failure in name resolution
At first glance, the error is understandable: the client cannot resolve the name of the DBMS server, a typical error for small networks where there is no local DNS server. As a solution, add an entry to the file hosts on the client, which gives no result ...
And now we remember what was said a little earlier. The client of the DBMS server is the 1C server, but not the client PC, therefore, the entry must be added on the 1C: Enterprise server to the file / etc / hosts on the Linux platform or on the Windows platform.
A similar error will occur if you forgot to add record type A for the DBMS server on the local DNS server.
An error occurred while performing an operation with an infobase
server_addr = NAME descr = 11001 (0x00002AF9): This host is unknown.
Like the previous one, this error is due to the client's incorrect resolution of the server name. This time it was the client PC. As a solution, add to the file / etc / hosts on Linux platform or in C: \ Windows \ System32 \ drivers \ etc \ hosts on the Windows platform, an entry of the form:
192.168.31.83SRV-1C-1204
where you specify the address and name of your 1C: Enterprise server. If using local DNS, add A record for 1C server.
DBMS error: DATABASE is not usable
A much more serious error, which indicates that you installed a version of PostgreSQL that is incompatible with 1C: Enterprise or made gross errors during installation, for example, did not install all the necessary dependencies, in particular the library libICU.
If you have sufficient experience in administering Linux systems, you can try to install the necessary libraries and re-initialize the DBMS cluster. Otherwise PostgreSQL is better to reinstall, remembering to delete the contents of the folder / var / lib / pgsql.
Also, this error can occur when using assemblies 9.1.x and 9.2.x [email protected] , see below for details.
DBMS error:
ERROR: could not load library "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so"
Quite a specific error specific to assemblies 9.1.x and 9.2.x [email protected] , may also lead to the previous error. The reason lies in an uncorrected error in the fasttrun.so library. The solution is to roll back to the assembly 9.0.x [email protected] .
DBMS error
ERROR: type "mvarchar" does not exist at character 31
Occurs if the database was created without the help of the 1C: Enterprise system. Remember, to work with 1C, databases should be created only using the tools of the 1C platform: via the console
or through the 1C launcher.
Database server not found
IMPORTANT: user "postgres" is not authenticated (by password)
A very simple mistake. The postgres DBMS superuser password is incorrect. There are two solutions: remember the password or change it. In the second case, you will need to change the password in the properties of all existing infobases using the snap-in Administration of 1C Enterprise servers.
Database server not found
FATAL: database "NAME" does not exist
Another very simple mistake. Its meaning boils down to the fact that the specified database does not exist. Most often it occurs due to an error in specifying the name of the base. It should be remembered that the 1C infobase in the cluster and the DBMS database are two different entities and may have different names. It should also be remembered that Linux systems are case sensitive and for them unf83 and UNF83 two different names.
Please enable JavaScript to view the
Tags:
Last week we brought a new server for 1C. HP Proliant 380 G6 2 2.58 GHz processors, 6 GB of RAM and three disks, each with a capacity of 72 GB and a rotational speed of 15K. Since Windows 2008 1C-nicknames do not digest (this is yet!), I installed Windows Server 2003 x64 Standart Edition.
The first rake came when we launched the server into "combat mode", naturally, renaming it: the 1C: Enterprise 8.2 Server Agent service began to crash (it starts, runs for 10 seconds and stops).
When connecting to the 1C: Enterprise 8.2 server through the server console, we get an error:
"Error connecting to the server 1C: Enterprise 8.2
server_addr = tcp: // s02: 1540 descr = Error on network access to server
(Windows Sockets - 10061 (0x0000274D). The connection was not established because the destination computer rejected the connection request.) Line = 590 file =. \ Src \ DataExchangeTcpClientItmpl.cpp "
When connecting to the database on this server, we get the following error:
"No workflow is running. Connection to the database is not possible."
Firewall is disabled, DEP is also disabled (enabled only for Windows services). Rebooting the server and reinstalling the platform did not help. We looked through the register twice, also to no avail.
It turns out that the 1C: Enterprise server cluster settings are stored in the srvinfo directory (the path to this directory can be viewed in the properties of the 1C: Enterprise 8.2 Server Agent service, the -d parameter). This directory stores the name of the cluster and its settings (including security) and lists of information security connected to this cluster and their settings. These are two files: srvinfo \ srvribrg.lst and srvinfo \ reg_1541 \ 1CV8Reg.lst. The old server name remained in these configuration files.
The next bug: V82.ComConnector stopped calling - wrote Class not registered. After a short googling, I found a solution to the problem on the resource http://www.gilev.ru/1c/hasp/
15. For COM connections to a 64-bit application server, use
possible only on the computer on which the key is installed
64-bit server 1C: Enterprise (and not from a terminal session).For
using V81.COMConnector on computers that only have access to
client keys, you can register the 32-bit V81.COMConnector in
COM +.
- start Component Services;
- create an empty COM + application with Activation type - Server application and a name, for example, V81_COMConnector, specify the Windows user name under which the component will run in the address space of a separate dllhost.exe process;
- in the Components branch add a new comcntr.dll component from the 1C: Enterprise load modules directory.
In this case, V81.COMConnector will run in a separate 32-bit process and can be used by both 32-bit and 64-bit applications.
I would like to add on my own that you need the user under whom the server 8.2 is running to add this new component to the users.
