Error while running transaction

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Error while running transaction

Профессионал

Группа: Пользователь
Сообщений: 2227
Регистрация: 14.9.2009
Вставить ник
Цитата
Из: Ленинград
Пользователь №: 1594
Страна: Россия
Город: Санкт-Петербург
Пол: Муж.

Репутация: 9

Строго говоря пробую с 8-ого Альта перейти на 9-й. Пытаюсь по https://www.altlinux.org/Update/p9
В терминале всплывает
E: Произошли ошибки при выполнении транзакции

И обновление перестаёт быть.
Попробовал перезагрузиться и продолжить из Синаптика где уже встал http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch/i586.
Итог тот же самый.

Во время подготовки к установке:

file /etc/ImageMagick-6/coder.xml from install of libImageMagick6-common-6.9.10.94-alt1 conflicts with file from package libImageMagick-6.9.4.7-alt2.M80P.1
********************многабукаф
libImageMagick-6.9.4.7-alt2.M80P.1
E: Error while running transaction

Чтение списков пакетов. Завершено
Построение дерева зависимостей. Завершено
Некоторые пакеты установить невозможно. Это может означать, что Вы
потребовали невозможного, либо пользуетесь нестабильным репозиторием.
Часть необходимых пакетов либо ещё не создана, либо была удалена
из каталога ‘Входящие’.
Эти сведения могут помочь найти выход из ситуации:

Следующие пакеты имеют неудовлетворенные зависимости:
kernel-modules-nvidia-std-def#440.82-alt1.328748.1:p9+252713.2200.2.1<>1591627333: Требует: nvidia_glx_390.132
shadow-utils: Требует: pam0(system-auth-use_first_pass-local)
tcb-utils: Для установки требует: pam0_tcb (= 1.1-alt1)
E: Извините, `битые’ пакеты
update-kernel: failed to install kernel-image-std-def-1:5.4.44-alt1:p9+252713.100.2.1<>1591626094 with modules
[root<>comp-pentium

И чего теперь делать.

Сообщение отредактировал robinzoid — 23.6.2020, 22:40

Источник

Error while processing transaction: error while sending transaction #1546

I was able to build agent from master. After running ./bin/agent/agent start -c ./bin/agent/dist/ I’m getting weird following error message

There is also no connection visible on dashboard. One other thing is version
Agent 6.0.0 — Commit: — Serialization version: but master is on 6.1.1.

Anyone can help here debug what is going on.

The text was updated successfully, but these errors were encountered:

The version is given at compile time by the build script using the last git tag. 6.0.0 probably correspond to the default value for the version :

First thing on top of my head : did you clone the repository or downloaded a zip ?

If you did indeed clone the repo could you tell me how you compiled the agent ?

I cloned it and then

I also tried the zip version but complained something about git-rev so I thought that clone is the right way.

Anything new around here? I can run some debugging if it helps?

@urosgruber as far as your the log message you’re seeing that looks like there was some kind of networking issue preventing the transactions (payloads) from being pushed to datadog at certain times. The forwarder, once the transaction fails re-enqueues it and is attempted later.

Are the errors in the log intermittent?

Could you please submit a flare to the support team so we can take a look at the logs and try to decide if this is indeed just a networking issue?

@truthbk I’ve manage to build agent manually but on the latest 6.2. Agent connects successfully and data is also visible on DD dashboard. Not sure if the issue was fixed with latest version or it was just develop build that cause this problem. I’ll check if 6.2 develop build also have similar issue.

@arbll I think error is now gone with 6.2.x Nothing was changed except I did pull from git and build with same command.

I am facing the same issue in kubernetes environment, below is the error message
I am using 6.10.1 version of datadog-agent image

I tried to send the flare but I am getting the error
Error: Post https://6-10-1-flare.agent.datadoghq.com/support/flare?api_key=***********************>: dial tcp: lookup 6-10-1-flare.agent.datadoghq.com: Temporary failure in name resolution

I have the same error as well, I am using the latest docker image and pure docker launch like below,

docker run -d —name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=xxxxx datadog/agent:latest

2019-08-02 02:37:50 UTC | CORE | ERROR | (pkg/forwarder/worker.go:142 in process) | Error while processing transaction: error while sending transaction, rescheduling it: Post https://6-13-0-app.agent.datadoghq.com/intake/?api_key=*************************: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I try to deploy datadog/agent:latest-jmx to AWS ECS fargate and keep getting the following errors:

• Error submitting payload to https://process.datadoghq.com/api/v1/collector: Post https://process.datadoghq.com/api/v1/collector: read tcp 10.0.10.10:39536->52.207.126.249:443: read: connection reset by peer
• TLS Handshake failure: read tcp 10.0.10.10:57718->52.45.28.194:443: read: connection reset by peer
• Too many errors for endpoint ‘https://6-13-0-app.agent.datadoghq.com/api/v1/series?api_key=******************************’: retrying later
  Is there anything special that needs to be done to deploy datadog docker container into that ECS Cluster (fargate)?

Getting the same issue on Google Kubernetes Engine (version 7.21.0 ), any idea what might be the cause ?

@joaquin386 @ocervell Were you able to fix this ? I’m getting the same errors on ECS (EC2).

Edit : This was fixed. I was setting env vars for proxy. Hence the timeouts.

@ocervell We’re seeing this in our Kubernetes clusters as well. Were you able to fix this? We get the following error, which originates in worker.go not the domain_forwarder.go. If other users are seeing similar logs, then it looks like this may be a problem with the retry routine itself (or at least how users have it configured).

I also face the same issue:
2021-05-11 22:51:00 UTC | PROCESS | ERROR | (pkg/forwarder/worker.go:178 in process) | Error while processing transaction: error while sending transaction, rescheduling it: Post «https://orchestrator.datadoghq.com/api/v1/orchestrator»: EOF

Same issue here. Datadog agent version 7.28.1 on AWS EKS 1.19.8

I am facing the same issue in Datadog agent version 7.29.0.Sent the flare to support.

UTC | CORE | ERROR | (pkg/forwarder/worker.go:179 in process) | Too many errors for endpoint ‘https://7-29-0-app.agent.datadoghq.com/api/v1/series?api_key=***************************’: retrying later

same issue here:
2021-10-04 20:39:52 UTC | PROCESS | ERROR | (pkg/forwarder/worker.go:183 in process) | Error while processing transaction: error while sending transaction, rescheduling it: Post «https://orchestrator.datadoghq.com/api/v1/orchestrator»: EOF

Same issue here:

I’m using the Datadag Lambda Extension installed using the Datadog Serverless Plugin, and having a few errors like those.

same issue here, I think something is wrong with their API and they dont want to surface it.

PROCESS | ERROR | (pkg/forwarder/worker.go:179 in process) | Too many errors for endpoint ‘https://process.datadoghq.com/api/v1/container’: retrying later

Error while processing transaction: error while sending transaction, rescheduling it: Post «https://7-31-0-app.agent.datadoghq.com/intake/?api_key=***************************bf62f»: context deadline exceeded (Client.Timeout exceeded while awaiting headers)

This is my error. I am using iptables ruling at DOCKER-USER chain level to Firewall my exposed containers. I believe the problem is related to it, because probably the packets are not reaching datadog server.

The thing is ifconfig | grep -i dropped shows that no packages have been dropped from eth0 or docker0.

What are the ports that need to be opened for out bounding packets?

We are also running into an issue with the sidecar container for the datadog-agent and getting the following errors on our ECS cluster:

Are there any updates to this issue? It is causing confusion with our logs in ECS.

A number of my datadog agents are working fine but a few new installations and the agents which were restarted recently facing similar issues. Error logs attached.

2021-12-08 04:33:18 EST | CORE | ERROR | (pkg/forwarder/transaction/transaction.go:108 in func4) | TLS Handshake failure: net/http: TLS handshake timeout 2021-12-08 04:33:18 EST | CORE | ERROR | (pkg/forwarder/worker.go:183 in process) | Error while processing transaction: error while sending transaction, rescheduling it: Post «https://*-**-*-app.agent.datadoghq.com/intake/?api_key=******************************»: net/http: TLS handshake timeout

It looks like this issue has become a bit of a random collection of connection issues (and some build issues).

In general, DataDog support is best suited to handle these situations: they can look at the circumstances, examine a flare, and make recommendations for the most successful configurations. I’ll close this issue up now.

Источник

Error: [ethjs-query] while formatting outputs from RPC #33

Issue Type

Not able to deploy smart contract.

Description

I am on ethereum private network (via running my local endpoint node ) and trying to deploy contract using metamask. The internal error from metamask show some Issue with ethjs-query module:-

Steps to reproduce

Deploy Smart contract using metamask which internally uses ethjs

Versions

The text was updated successfully, but these errors were encountered:

@NEO2756 I’m getting this as well

Got it working. Was an issue with my web3 provider

@adamsoffer What was the issue? I am also facing same issue.

@adamsoffer what was the issue?

Apologies, I can’t remember the specifics.

@ahmed-numaan @stackchain if you are launching dapps from truffle develop and getting this or similar errors, try reseting your metamask accounts (settings > advanced > reset account). Worked for me. I was getting ‘incorrect nonce’ errors and some other weird ones, believe it stemmed from the fact the local develop chain uses a persistent mnemonic (unlike ganache, which spins up a new one each time). I think metamask was getting confused by my old transactions in previous run start launches getting mixed in with new ones after fresh deployments

Thanks this worked for me!

👍🏼 Glad to hear it

same for me 🙁
did you deal with that?

same for me 🙁
did you deal with that?

Have you found a solution?

same for me 🙁
did you deal with that?

Have you found a solution?

I am getting this error while following this example, https://dev.to/dabit3/the-complete-guide-to-full-stack-ethereum-development-3j13 , whenever I sign the transaction it happens.

I don’t know if you solved it, but apparently it’s a metamask problem. I reset my wallet and it worked after.

Same error on HardHat node

same for me 🙁
did you deal with that?

Have you found a solution?

have you find the any solution for it. cause i got the same error while deploying some small contracts with the help of meta mask and remix.

Источник

Troubleshoot a Full Transaction Log (SQL Server Error 9002)

Applies to: SQL Server (all supported versions)

Option 1: Run the steps directly in an executable notebook via Azure Data Studio

Before attempting to open this notebook, check that Azure Data Studio is installed on your local machine. To install, go to Learn how to install Azure Data Studio.

Option 2: Follow the step manually

This topic discusses possible responses to a full transaction log and suggests how to avoid it in the future.

When the transaction log becomes full, SQL Server Database Engine issues a 9002 error. The log can fill when the database is online, or in recovery. If the log fills while the database is online, the database remains online but can only be read, not updated. If the log fills during recovery, the Database Engine marks the database as RESOURCE PENDING. In either case, user action is required to make log space available.

This article is focused on SQL Server. For more specific information on this error in Azure SQL Database and Azure SQL Managed Instance, see Troubleshooting transaction log errors with Azure SQL Database and Azure SQL Managed Instance. Azure SQL Database and Azure SQL Managed Instance are based on the latest stable version of the Microsoft SQL Server database engine, so much of the content is similar though troubleshooting options and tools may differ.

Common reasons for a full transaction log

The appropriate response to a full transaction log depends on what conditions caused the log to fill. Common causes include:

• Log not being truncated
• Disk volume is full
• Log size is set to a fixed maximum value or autogrow is disabled
• Replication or availability group synchronization that is unable to complete

How to resolve a full transaction log

The following specific steps will help you find the reason for a full transaction log and resolve the issue.

1. Truncate the Log

A very common solution to this problem is to ensure transaction log backups are performed for your database which will ensure the log is truncated. If no recent transaction log history is indicated for the database with a full transaction log, the solution to the problem is straightforward: resume regular transaction log backups of the database.

Log truncation explained

There’s a difference between truncating a transaction log and shrinking a transaction log. Log Truncation occurs normally during a transaction log backup, and is a logical operation which removes committed records inside the log, whereas log shrinking reclaims physical space on the file system by reducing the file size. Log truncation occurs on a virtual-log-file (VLF) boundary, and a log file may contain many VLFs. A log file can be shrunk only if there’s empty space inside the log file to reclaim. Shrinking a log file alone can’t solve the problem of a full log file, instead, you must discover why the log file is full and can’t be truncated.

Data that is moved to shrink a file can be scattered to any available location in the file. This causes index fragmentation and might slow the performance of queries that search a range of the index. To eliminate the fragmentation, consider rebuilding the indexes on the file after shrinking. For more information, see Shrink a database.

What is preventing log truncation?

To discover what is preventing log truncation in a given case, use the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view. For more information, see sys.databases (Transact-SQL). For descriptions of factors that can delay log truncation, see The Transaction Log (SQL Server).

The following set of T-SQL commands will help you identify if a database transaction log isn’t truncated and the reason for it. The following script will also recommend steps to resolve the issue:

If the database was in recovery when the 9002 error occurred, after resolving the problem, recover the database by using ALTER DATABASE database_name SET ONLINE.

LOG_BACKUP log_reuse_wait

The most common actions you can consider here is to review your database recovery model and backup the transaction log of your database.

Consider the database’s recovery model

The transaction log may be failing to truncate with LOG_BACKUP log_reuse_wait category, because you have never backed it up. In many of those cases, your database is using FULL or BULK_LOGGED recovery model, but you did not back up transaction logs. You should consider each database recovery model carefully: perform transaction log backups on all databases in FULL or BULK LOGGED recovery models to minimize occurrences of error 9002. For more information, see Recovery Models.

Back up the log

Under the FULL or BULK_LOGGED recovery model, if the transaction log has not been backed up recently, backup might be what is preventing log truncation. You must back up the transaction log to allow log records to be released and the log truncated. If the log has never been backed up, you must create two log backups to permit the Database Engine to truncate the log to the point of the last backup. Truncating the log frees logical space for new log records. To keep the log from filling up again, take log backups regularly and more frequently. For more information, see Recovery Models.

A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb system database. To review the complete backup history of a database, use the following sample script:

A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb system database. For more information on backup history, see Backup History and Header Information (SQL Server).

Create a transaction log backup

Example of how to back up the log:

If the database is damaged, see Tail-Log Backups (SQL Server).

ACTIVE_TRANSACTION log_reuse_wait

The steps to troubleshoot ACTIVE_TRANSACTION reason include discovering the long running transaction and resolving it (in some case using the KILL command to do so).

Discover long-running transactions

A very long-running transaction can cause the transaction log to fill. To look for long-running transactions, use one of the following:

This dynamic management view returns information about transactions at the database level. For a long-running transaction, columns of particular interest include the time of the first log record (database_transaction_begin_time), the current state of the transaction (database_transaction_state), and the log sequence number (LSN) of the begin record in the transaction log (database_transaction_begin_lsn).

• DBCC OPENTRAN. This statement lets you identify the user ID of the owner of the transaction, so you can potentially track down the source of the transaction for a more orderly termination (committing it rather than rolling it back).

Kill a transaction

Sometimes you just have to end the transaction; you may have to use the KILL statement. Please use this statement very carefully, especially when critical processes are running that you don’t want to kill. For more information, see KILL (Transact-SQL)

AVAILABILITY_REPLICA log_reuse_wait

When transaction changes at primary Availability replica are not yet hardened on the secondary replica, the transaction log on the primary replica cannot be truncated. This can cause the log to grow, and can occur whether the secondary replica is set for synchronous or asynchronous commit mode. For information on how to troubleshoot this type of issue see Error 9002. The transaction log for database is full due to AVAILABILITY_REPLICA error

CHECKPOINT log_reuse_wait

No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file (VLF). (All recovery models)

This is a routine reason for delaying log truncation. If delayed, consider executing the CHECKPOINT command on the database or examining the log VLFs.

For more information on log_reuse_wait factors

2. Resolve full disk volume

In some situations the disk volume that hosts the transaction log file may fill up. You can take one of the following actions to resolve the log-full scenario that results from a full disk:

Free disk space

You might be able to free disk space on the disk drive that contains the transaction log file for the database by deleting or moving other files. The freed disk space allows the recovery system to enlarge the log file automatically.

Move the log file to a different disk

If you cannot free enough disk space on the drive that currently contains the log file, consider moving the file to another drive with sufficient space.

Log files should never be placed on compressed file systems.

See Move Database Files for information on how to change the location of a log file.

Add a log file on a different disk

Add a new log file to the database on a different disk that has sufficient space by using ALTER DATABASE ADD LOG FILE . Multiple log files for a single database should be considered a temporary condition to resolve a space issue, not a long-term condition. Most databases should only have one transaction log file. Continue to investigate the reason why the transaction log is full and cannot be truncated. Consider adding temporary additional transaction log files as an advanced troubleshooting step.

Utility script for recommended actions

These steps can be partly automated by running this T-SQL script which will identify logs files that using a large percentage of disk space and suggest actions:

3. Change log size limit or enable Autogrow

Error 9002 can be generated if the transaction log size has been set to an upper limit or Autogrow is not allowed. In this case, enabling autogrow or increasing the log size manually can help resolve the issue. Use this T-SQL command to find such log files and follow the recommendations provided:

Increase log file size or enable Autogrow

If space is available on the log disk, you can increase the size of the log file. The maximum size for log files is two terabytes (TB) per log file.

If autogrow is disabled, the database is online, and sufficient space is available on the disk, do either of these:

• Manually increase the file size to produce a single growth increment. These are general recommendations on log size growth and size.
• Turn on autogrow by using the ALTER DATABASE statement to set a non-zero growth increment for the FILEGROWTH option. See Considerations for the autogrow and autoshrink settings in SQL Server

In either case, if the current size limit has been reached, increase the MAXSIZE value.

Источник