When a cron job runs, I get an email that says
HTTP request sent, awaiting response... 200 OK
Length: 19 [text/html]
Saving to: “filefeed.16”
0K 100% 4.93M=0s
2017-03-23 10:10:04 (4.93 MB/s) - “filefeed.16” saved [19/19]
So it's my understanding that Saving to: “filefeed.16” means that is storing this file somewhere in my server, where is it?
After looking a few hours, I found it was quite simple, depending on the user who is running the cron job, it will store this file in the user's directory, for example, let's say I am using user_03, it will save it on /home/user_03/.
Related
readline-6.2-11.el7.x86_64.rpm FAILED
http://mirror.verinomi.com/centos/7.9.2009/os/x86_64/Packages/readline-6.2-11.el7.x86_64.rpm: [Errno 12] Timeout on http://mirror.verinomi.com/centos/7.9.2009/os/x86_64/Packages/readline-6.2-11.el7.x86_64.rpm: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')
I got an error while updating yum.
yum update
Try:
time wget http://mirror.verinomi.com/centos/7.9.2009/os/x86_64/Packages/readline-6.2-11.el7.x86_64.rpm
time wget http://mirror.verinomi.com/centos/7.9.2009/os/x86_64/Packages/readline-6.2-11.el7.x86_64.rpm
--2022-08-25 11:24:31-- http://mirror.verinomi.com/centos/7.9.2009/os/x86_64/Packages/readline-6.2-11.el7.x86_64.rpm
Resolving mirror.verinomi.com (mirror.verinomi.com)... 193.162.43.250
Connecting to mirror.verinomi.com (mirror.verinomi.com)|193.162.43.250|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 197696 (193K) [application/x-rpm]
Saving to: ‘readline-6.2-11.el7.x86_64.rpm’
>
readline-6.2-11.el7.x86_64.rpm 100%[=====================================================================================>] 193,06K 555KB/s in 0,3s
2022-08-25 11:24:32 (555 KB/s) - ‘readline-6.2-11.el7.x86_64.rpm’ saved [197696/197696]
real 0m0,758s
user 0m0,010s
sys 0m0,009s
If there is a big delay check your internet connection. If your internet speed is really low (like downloading "Less than 1000 bytes/sec the last 30 seconds") it will stop the update through this mirror and may try another.
I am trying to convert ms-office files to pdf using gotenberg api. For some files, i am getting unoconv PDF context deadline exceeded with 503 status. I have increased the read, write and process timeout to 60 secs. How can i resolve this issue? What is the the maximum time take to convert the file? What is the maximum request can be handled by one gotenberg instance?
Try increase timeout in gotenberg by passing --api-timeout to container start command
gotenberg:
image: gotenberg/gotenberg:7
command: gotenberg --log-level=info --api-timeout 400s
I'm seeing the following warning in the /var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log:
2021-10-06T06:39:23Z W! [outputs.cloudwatchlogs] Invalid SequenceToken used, will use new token and retry: The given sequenceToken is invalid. The next expected sequenceToken is: 49619410836690261519535138406911035003981074860446093650
But there is no mention about which file is really the one that it's failing. Not even when I add "debug": true to the /opt/aws/amazon-cloudwatch-agent/bin/config.json.
cat /opt/aws/amazon-cloudwatch-agent/bin/config.json|jq .agent
{
"metrics_collection_interval": 60,
"debug": true,
"run_as_user": "root"
}
I have many (28) files in my .logs.logs_collected.files.collect_list section of the config.json file, so how can I find which file is exactly causing trouble?
As of 2021-11-29 a PR to improve the log messages has been merged to the cloudwatch-agent but a new version of the cloudwatch-agent has not been released yet, the next version after v1.247349.0 will likely include a fix for this.
The fix will change the log statements to say
INFO: First time sending logs to %v/%v since startup so sequenceToken is nil, learned new token: xxxx: yyyy: This is an INFO message, as this behaviour is expected at startup for example.
WARN: Invalid SequenceToken used (%v) while sending logs to %v/%v, will use new token and retry: xxxxxv: This on the other hand is not expected and may mean that someone else is writing to the loggroup/logstream concurrently.
If those warnings come right after a restart of the cloudwatch agent (cwagent) then you can safely ignore them, it's expected behaviour . The cloudwatch agent does not save the next sequence token in its persistent state so on restart it will "learn" the correct sequence number by issuing a PutLogEvent with no sequence token at all, that returns an InvalidSequenceTokenException with the next sequence token to use. So it's expected to see those at startup, anyway I proposed a PR to amazon-cloudwatch-agent to improve those log messages.
If the "Invalid SequenceToken used" is seen long after the restart then you may have other issues.
The "Invalid SequenceToken used" error usually means that two entities/sources are trying to write to the same log group/log stream as mentioned in 2 (which is really for the old awslogs agent but still useful):
Caught exception: An error occurred (InvalidSequenceTokenException)
when calling the PutLogEvents operation: The given sequenceToken is
invalid[…] -or- Multiple agents might be sending log events to log
stream[…] – You can't push logs from multiple log files to a single
log stream. Update your configuration to push each log to a log
stream-log group combination.
I could be that the amazon cloudwatch agent itself it's trying to upload the same file twice because you have duplicates in your config.json.
So first print all your log group / log stream pairs in your config.json with:
cat /opt/aws/amazon-cloudwatch-agent/bin/config.json|jq -r '.logs.logs_collected.files.collect_list[]|"\(.log_group_name) \(.log_stream_name)"'|sort
which should give an output similar to:
/tableauserver/apigateway apigateway_node5-0.log
/tableauserver/apigateway control_apigateway_node5-0.log
/tableauserver/appzookeeper appzookeeper-discovery_node5-1.log
...
/tableauserver/vizqlserver vizqlserver_node5-3.log
Then you can use uniq -d to find the duplicates in that list with:
cat /opt/aws/amazon-cloudwatch-agent/bin/config.json|jq -r '.logs.logs_collected.files.collect_list[]|"\(.log_group_name) \(.log_stream_name)"'|sort|uniq -d
# The list should be empty otherwise you have duplicates
If that command produces any output it means that you have duplicates in your config.json collect_list.
I personally think that cwagent itself should print the "offending" loggroup/logstream in the logs so I opened in issue in amazon-cloudwatch-agent GitHub page.
Messages in my eclipse (testNG & selenium) projects are getting so much now that wanted outputs from sysout command are getting lost between them. This started recently. They were never these much. I heard there is a way to get rid of the unwanted warning messages or reduce them, at least. How can this be possibly achieved?
I get duplicates of messages like:
[BaseMessageSender] Connection established, starting reader thread
[BaseMessageSender] ReaderThread waiting for an admin message
[JsonMessageSender] Sending message [GenericMessage ==> suiteCount:1,
testCount:1]
TestNG] Time taken by org.testng.reporters.jq.Main#11531931: 80 ms
[TestNG] Time taken by org.testng.reporters.EmailableReporter2#35bbe5e8: 19 ms
[TestNG] Time taken by org.testng.reporters.XMLReporter#3f0ee7cb: 7 ms
TestNG] Time taken by [FailedReporter passed=0 failed=0 skipped=0]: 1 ms
[Utils] Attempting to create C:\Filepath\....
right click on the file you want to run ,then click on the Run Configurations then make sure verbose and Debug checkbox is unchecked .
image link
I am using asterisk 11.9.0 everything works fine but cli shows unknown sip registrations with my current code running
my cli output
-- Hungup 'DAHDI/i1/9560790782-2fd2'
[Jun 24 14:55:24] NOTICE[3637]: chan_sip.c:25757 handle_request_register: Registration from '"4001" <sip:4001#182.74.197.19:5060>' failed for '37.8.47.82:22939' - Wrong password
[Jun 24 14:55:25] NOTICE[3637]: chan_sip.c:25757 handle_request_register: Registration from '"3822" <sip:3822#182.74.197.19:5060>' failed for '37.8.47.82:23187' - Wrong password
[Jun 24 14:55:29] NOTICE[3637]: chan_sip.c:25757 handle_request_register: Registration from '"5555" <sip:5555#182.74.197.19:5060>' failed for '37.8.47.82:22848' - Wrong password
how can i remove this because my dialplan is taking too much time to execute as compared to the past.
Any help would be appreciated.
Very likly that is automated programs(bots) with goal find your secrets/on success call out to Cuba or other costly destinations.
Every asterisk installation need have at least rate limiter - usually fail2ban.org used. That will prevent bots from spamming too fast.