the latest version dont support mysql 8.0 as storage

I fount the latest docker image only can work with lower version mysql,eg 5.7.
but download the history version of 2.21.5,it can works with mysql 8.0 fine.
Mean while,I checked the docker hub image version with github's release version,is consistent too.
Is there any problem occurs when merging the pull request?

Would you open a PR with the fix?
lør. 2. apr. 2022, 07:47 skrev luoqingsong @.***>:

I fount the latest docker image only can work with lower version mysql,eg
5.7.
—
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/issues/3441, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYATBKU5DJ2B5RRUFHGTVC7NOTANCNFSM5SKN6EBQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

ok,i should take time to review the history commits of changes.
I try it ,thanks very much.

not fixed yet

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.mariadb.jdbc.internal.com.send.authentication.SendGssApiAuthPacket
Brothers, is it the same error log?

@jcchavezs Could you please clarify whether Zipkin is going to support MySQL 8 in near future?

Would be a nice enhanchment, running years old software makes me nervious ;)
And from the looks of it the bundled mysql for docker is mysql 3.x!!!!!!!!
Please fix this :)

+1

I use zipkin version 2.24.3 and mysql version 8.0.21
I found that if I downloaded zipkin from docker and used mysql persistence, I would report version compatibility errors
But pushing the 2.24.3 jar package onto docker and using mysql persistence is fine
It's weird, I tested three servers with the same problem

zipkin tests run against our docker image which is MySQL 10.11.7


gearbest stylesheet and sofascore blocked by spark!

even though you removed some sources, the problems remain in spark
(after last time it was blocking firefox sync and facebook)!
the new ones I run into are gearbest stylesheet and sofascore,
amazing, who blocks those and why?
using all that many hosts and having to whitelist all the many entres seems useless, don't you think?
anyway, I searched spark sources I found no results,
so the above should be in those "black boxes" sources:
Ador Energized, Adguard Ads & Spyware, Easylist Adserver & Lite, EasyPrivacy, Fanboy Cookiemonster, LightSwitch Extended
really, where are the links for them?
does adguard and easylist have a hosts blocking solution online? because I think they are more "ublock"-like, also, amazing that "Fanboy Cookiemonster" is even there,
this is to be used specifically by users that use ublock or adguard,
cookie notices can't be blocked by hosts solutions of course

For those blocked/broken sites ~ Just send us the log/domains that were blocked!
For Energized Core, Adguard Mobile Ads & Mobile Spyware, EasyList Adservers, EasyList Lite and Fanboy Cookiemonster
EasyPrivacy and Lightswitch Extended was removed. I updated the readme before removing the hosts! (and, somehow I ended up forgetting to add them back!)
And For your kind information, we got advanced scripts to convert those non-hosts lists to hosts. Here is the script ~ Energized Converter
*. if you really think we are that dumb! kindly stop using Energized for real good! :)

I don't think you're dumb, I wouldn't be here if I did,
I'm just trying to find out who is,
ok, thanks, give me a minute to check

what I meant is! We are open! The scripts we use, the sources we use, all are open, and you can easily check everything right from our git. You should have checked everything before submitting an issue.
Take your time and help us with the logs.

ok, got it, both the problems are here:
https://raw.githubusercontent.com/EnergizedProtection/block/master/assets/active/filter/ador-energized.txt
css.gbtcdn.com
gloimg.gbtcdn.com
uidesign.gbtcdn.com
www.sofascore.com
all of these should be whitelisted

That's fine! Then we will look into this and fix with next release.

actually there are a lot you've got to whitelist:
activations.cdn.mozilla.net appbrain.com blocklist.addons.mozilla.org broker-live.mozillamessaging.com cdn.optimizely.com code.cdn.mozilla.net css.gbtcdn.com data.mozilla.com fhr.cdn.mozilla.net fhr.data.mozilla.com gloimg.gbtcdn.com googletagmanager.com googletagservices.com input.mozilla.org keepimg.com mozsocial.cliqz.com mywot.com pipe.skype.com push.services.mozilla.com search.services.mozilla.com self-repair.mozilla.org services.addons.mozilla.org shavar.services.mozilla.com snippets.cdn.mozilla.net snippets.mozilla.com syndication.twimg.com tiles.services.mozilla.com www.googletagmanager.com www.googletagservices.com www.mywot.com www.sofascore.com
one day before I found mywot.com was blocked,
just run a check on the above and tell me if he who creates this list is dumb or not
(or maybe he's.. drunk when he's creating it),
I won't be using this particular one anymore because I've run into many "accidents" and
things don't seem to be getting better, sorry
I don't like such lists anyway, neither do I like the one by jawz (mobileadtrackers),
because it contains many false positives too and it shouldn't be in spark in my opinion


change plain text messages to be encoded using MIME

Plain text messages with accents are not shown well in email clients. Adding MIME encoding solves #24 .

Well, there wasn't any interest in merging this ,closing.


CIF-1325	- Automatically create a product binding after creating a configuration

Description
The product binding creation is handled by a ResourceChangeListener that kicks off when a new node is added under /conf. The product binding name follows this pattern: <configuration name>-<store view>.
The operations are performed using a new service user which has jcr:read access on /conf and rep:write access on /var/commerce/products.
Notes:

deleting the configuration doesn't delete the binding. The listener doesn't handle deletions because of a technical limitation: when a resource is deleted there is absolutely no information regarding the resource itself, just the path. There are ways to determine the properties, using the VersionManager, but they are not 100% reliable I think it's more trouble than it's worth.
the bindings are only created when a configuration is created. For configurations created prior to the upgrade, the bindings must be created manually.

Related Issue
CIF-1325
Motivation and Context
Automate configuration of new stores.
How Has This Been Tested?
Functional tests, unit tests
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes and the overall coverage did not decrease.
[x] All unit tests pass on CircleCi.
[x] I ran all tests locally and they pass.

lgtm. Regarding the deletion. If a config is deleted and we only get the path, we could determine the config root path from it (without the commerce bucket name) and query for all bindings that point to that config and delete them, right?

@herzog31 @cjelger the path of the config contains the name of the configuration but doesn't contain the store view. For a configuration /conf/venia/en with store view default the corresponding binding name is /var/commerce/products/en-default. The deletion event will only contain the /conf/venia/en path.

@dplaton Here https://github.com/adobe/commerce-cif-connector/pull/121/files#diff-eff6c4447dee114924edf543d12fb303R111 you store the config path in the binding. Can't you query all bindings with the path to the config that was deleted?

@dplaton Here https://github.com/adobe/commerce-cif-connector/pull/121/files#diff-eff6c4447dee114924edf543d12fb303R111 you store the config path in the binding. Can't you query all bindings with the path to the config that was deleted?

Oh, I now understand what you said :). Yes, I can do this.

@dplaton You can also simply delete all bindings with names like /var/commerce/products/en- ... no?


@QueryEmbedded generates a wrong type in subclass in some cases

If fooOfSuperclass is declared like this:
package com.company.framework;
@QueryEntity
public class Superclass {
    ...
    @QueryEmbedded
    private List<IdNamePair<String>> fooOfSuperclass = new ArrayList<IdNamePair<String>>();
    ...
}

the generated Q-class is:
@Generated("com.mysema.query.codegen.EntitySerializer")
public class QSuperclass extends EntityPathBase<Superclass> {
    ...
    public final ListPath<IdNamePair<String>, QIdNamePair> fooOfSuperclass = this.<IdNamePair<String>, QIdNamePair>createList("fooOfSuperclass", IdNamePair.class, QIdNamePair.class);
    ...
}

When the Superclass is inherited:
package com.company.client
@QueryEntity
public class Subclass extends com.company.framework.Superclass {
    private int number;
}

The generated Q-class for the Subclass is:
@Generated("com.mysema.query.codegen.EntitySerializer")
public class QSubclass extends EntityPathBase<Subclass> {
    ...
     //inherited
    public final ListPath<com.company.framework.IdNamePair<String>, ComparablePath<com.company.framework.IdNamePair<String>>> fooOfSuperclass = _super.fooOfSuperclass;
    public final NumberPath<Integer> number = createNumber("number", Integer.class);
   ...
}

The problem is that the type parameter of this.fooOfSuperclass is ComparablePath instead of QIdNamePair. This causes the QSubclass not to compile since type parameter of _super.fooOfSuperclass is QIdNamePair.

This issue appeared only when the supertype appeared in a different module. External QueryEmbedded types are now properly tracked.


Add i18n options?

I liked the idea of the plugin a lot. I love the recurring tasks feature. Would it be possible to either merge your functionality with this plugin or add better i18n support?

Thanks for your suggestion. There are great difficulties in merging with Task List Plugin, so I will not consider it at present, but I will try my best to optimize i18n support.

@RogerHuHu  -  https://github.com/RogerHuHu/siyuan-plugin-schedule-manager/blob/4f3991c6591b4f79ba68e053b8f54845b7af6232/src/components/Calendar.vue#L76C1-L77C1
Does the locale have to be hard-coded?

Adding the above option gives this, but the setting doesn't persist. Need your help with persistence.


Storing private keys on wallet?

I'm trying to wrap my head around how to use Nami to authenticate users for an application which also stores off-chain, private user data. I posted the question on StackExchange, but thought it'd be good to ask here as well.
The problem is that the backend server must verify that a user has access to their wallet. Following the guide on this repo, I was not able to figure out how to implement this. If it is not possible right now, one solution could be to establish a handshake for generating a private key, which can be stored on the wallet and sent to the backend for verification. This would essentially act like a password for traditional sites, and thus Nami would perform similarly to a password manager.
Another solution is to skip centralized storage of private data altogether, and put it on the user's local file system instead. This has its own downsides, mainly that the API for reading local files is not widely supported, and it is difficult to build multi-device support.
In other words, what are the limitations to using Nami wallet for user authentication, and how can they be solved?

Answered sufficiently here. Nami provides a signData function, which can be used authenticate with backend.


Integration with Telemetry

Hi, this is more of question than issue.
I wonder if there is a way to send events to PromEx which are already in Telemetry. I guess attaching additional Telemetry handler would be necessary, but how to send/forward those events to PromEx.
Basically my question is would it be possible to resend events to PromEx without custom plugin implementation.
It is related to this question: https://github.com/TheRealReal/hackney_telemetry/issues/5
Thanks,
Leon

Hello and thanks for reaching out! I think there might be a bit of a misunderstanding here. Telemetry is merely a tool for exposing events via synchronous function dispatch. What attaches to those telemetry events becomes the responsibility of the library user.
PromEx takes on a lot of that responsibility by dealing with the execution and attaching-to of telemetry events and formats the events in a way that you can get those metrics into Prometheus. If you need to capture Prometheus metrics for any library that supports telemetry, you will need to write a PromEx plugin to support that library. In this particular instance, you will need to go through the supported telemetry events (https://github.com/TheRealReal/hackney_telemetry#telemetry-metrics) and find out what Prometheus data type fits that data point best and wrap that logic into a plugin that can be loaded by PromEx.
Hope that helps!

Awesome! Feel free to ping me on Elixir Slack if you need any help with the plugin :)


Release4 v2 apps

PLEASE READ
Following a recent back-end update, all contributors with a local clone or fork of our repository are required to run yarn install. This does not apply to direct page edits.

[ ] Yes, I've run yarn install
[ ] No, does not apply to me

Purpose of this pull request
This pull request...

Select the type of change:

[ ] Minor Changes - Typos, formatting, slight revisions, .clabot
[ ] Update Content - Revisions, updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

@priyansh-sumo, the build-and-deploy check is failing on an import command for ../../reuse/apps/app-install-v2.md. I suspect that you need to change .../.../" to .../.../.../` on a few files that are one more level deep than the others. Could you make needed corrections and verify that your local build works in yarn?


Add event cancellation

closes #4178

[x] Backend: Added RPC for event cancellation and deletion
[x] Backend: Adjusted Event DB schema
[x] Backend: Deny selected actions on cancelled event
[x] Backend: Deleted events should never show up
[x] Frontend: Add button to cancel event
[ ] Frontend: Display cancelled events accordingly

[ ] Grey cancelled events out in overview
[x] Make all buttons disabled for cancelled events
[ ] Make it visually clear the event is cancelled

Backend checklist

[x] Formatted my code by running autoflake --exclude src/proto -r -i --remove-all-unused-imports src && isort . && black . in app/backend
[x] Added tests for any new code or added a regression test if fixing a bug
[x] All tests pass
[x] Run the backend locally and it works
[x] Added migrations if there are any database changes, rebased onto develop if necessary for linear migration history

Web frontend checklist

[ ] Formatted my code with make format
[ ] There are no warnings from make lint
[ ] There are no console warnings when running the app
[ ] Added any new components to storybook
[ ] Added tests where relevant
[ ] All tests pass
[ ] Clicked around my changes running locally and it works
[ ] Checked Desktop, Mobile and Tablet screen sizes

Let me know if you need anything for this.

@aapeliv @jesseallhands How do we want to display cancelled events? In my idea, they should later not show up in event searches at all, but should still show up under a tab "My Events" or so, if you joined one previously.
In the current version, as we don't have too many events yet, I guess we display cancelled events as well, but should make it visually clear that they are/were cancelled. How should we do that best? (I am slightly limited by my frontend dev skills here) My idea for now was to grey them out a bit and include a "cancelled" badge.

@aapeliv @jesseallhands How do we want to display cancelled events? In my idea, they should later not show up in event searches at all, but should still show up under a tab "My Events" or so, if you joined one previously.
In the current version, as we don't have too many events yet, I guess we display cancelled events as well, but should make it visually clear that they are/were cancelled. How should we do that best? (I am slightly limited by my frontend dev skills here) My idea for now was to grey them out a bit and include a "cancelled" badge.

Yes, I think cancelled events should be under a separate cancelled events tab and we should use a bright "cancelled!" pill (badge) to mark it.
As far as deleted events go, those shouldn't be shown on the website at all, but should still be queryable on the backend.

So I chose to include a switch for now to display cancelled events. I think soon, as discussed, we could have a new events page layout (see https://github.com/Couchers-org/couchers/issues/3989).
Cancelled events are greyed out and highlighted with a "cancelled" chip. On the page of a cancelled event the buttons are disabled and greyed out.
Deleted events can't be queried at all through the API, but are still available in the database. I thought it might be better to avoid accidentally displaying a deleted event. But an alternative could be that only superusers can query deleted events.

There are 4 different places where events are currently listed, this is how I chose to deal with cancelled events for each of these:

Dashboard: Cancelled events are not shown (Here ListMyEvents is called, where a include_cancelled flag could be used to include these though)
Events page: Cancelled events are by default not shown, but can be toggled to be shown
Community page overview: Cancelled events are not shown
Community page events tab: Cancelled events are not shown

I think viewing cancelled events does only make sense if wondering why an event I joined previously was cancelled or to look for other attendees/information and is therefore quite conscious.

There are 4 different places where events are currently listed, this is how I chose to deal with cancelled events for each of these:

Dashboard: Cancelled events are not shown (Here ListMyEvents is called, where a include_cancelled flag could be used to include these though)

Events page: Cancelled events are by default not shown, but can be toggled to be shown

Community page overview: Cancelled events are not shown

Community page events tab: Cancelled events are not shown

I think viewing cancelled events does only make sense if wondering why an event I joined previously was cancelled or to look for other attendees/information and is therefore quite conscious.

I think this is great!

@spreeni is this ready to go? If you rebase I can review and we can merge!

@aapeliv I merged your new notification changes into the branch, please have a look again.
Locally I am having some issues with the new notification payloads though. I followed the example with event update notifications, but I am getting an AttributeError: occurence_id within the jobs, apparently the job payload is empty. I have generated protos, but do you maybe have an idea what this could be?

I am getting an AttributeError: occurence_id within the jobs

OcurRence has two Rs, is that it? I mis-spell this word about 95% of the time.


Update for version 1.7 of the slack plugin

Any news on this getting merged? I could really use it.

Looks good, thanks!


Show a different message for the error state in form submission.

Currently, the form shows the same Please enter a valid email address! message for both invalid and error states.
Invaid:

Error:

The mail server is set up with a few whitelisted emails, that's why I recieve error. So, I think there needs to be a different message to the error state, for example, "An error occurred, ..."
Technical details

Casper Version: 3.0.0
Ghost Version: 3.0.0

Thanks for this feedback! We use this repository for tracking bugs in Casper, but we have a dedicated forum category for feedback about the members beta and any features relating to it :)
https://forum.ghost.org/c/members


Links in the readme are broken

Links in the landing page of this repo lead to broken pages / 404s

You caught me right in the middle of breaking changes :) (See #23). I'll have everything fixed when I push v3.0 later today.

Fixed in e77bb568aa92972cf63995d15b038de5dd53ecc1.


[BUG] Multi-Master Sync keeps restarting (one after the other).

Describe the bug
Multi-master about a 100ms link with about 1gb of data restarts sync within 1 minute of completing a sync from the other side.
So for example, after both servers come online:
Server A replicates from server B
Completes replication, stays stable for 20 seconds.
Server B replicates from server A
Completes replication, stays stable for 20 seconds.
[REPEATS]
To reproduce
Please find attached config from both servers
Server A
bind <IP_ADDRESS>
protected-mode no
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
pidfile /var/run/keydb/keydb-server.pid
loglevel notice
logfile /var/log/keydb/keydb-server.log
databases 16
always-show-logo yes
set-proc-title yes
proc-title-template "{title} {listen-addr} {server-mode}"
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
rdb-del-sync-files no
dir /var/lib/keydb
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-diskless-load disabled
repl-disable-tcp-nodelay yes
repl-backlog-size 1024mb
replica-priority 100
acllog-max-len 128
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
lazyfree-lazy-user-del no
lazyfree-lazy-user-flush no
oom-score-adj no
oom-score-adj-values 0 200 800
disable-thp yes
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes
jemalloc-bg-thread yes
server-threads 2
multi-master yes
active-replica yes
replicaof <IP_ADDRESS> 6379

Server B
bind <IP_ADDRESS>
protected-mode no
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
pidfile /var/run/keydb/keydb-server.pid
loglevel notice
logfile /var/log/keydb/keydb-server.log
databases 16
always-show-logo yes
set-proc-title yes
proc-title-template "{title} {listen-addr} {server-mode}"
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
rdb-del-sync-files no
dir /var/lib/keydb
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-diskless-load disabled
repl-disable-tcp-nodelay yes
repl-backlog-size 1024mb
replica-priority 100
acllog-max-len 128
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
lazyfree-lazy-user-del no
lazyfree-lazy-user-flush no
oom-score-adj no
oom-score-adj-values 0 200 800
disable-thp yes
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes
jemalloc-bg-thread yes
server-threads 2
multi-master yes
active-replica yes
replicaof <IP_ADDRESS> 6379

Expected behavior
I would expect the servers (after completing their initial replication process) to remain in sync and not drop and resync.
Additional information
Version 6.2.2
Either side can remain stable if we run single-direction replication.
Both (Server A and Server B) also act as Masters for 6+ Slave servers within the same zone. This works perfectly.
Pertinent Logs
1587063:1587086:S 14 Feb 2023 14:54:03.459 * MASTER <-> REPLICA sync: Finished with success
1587063:1587087:S 14 Feb 2023 14:54:03.499 * Replica <IP_ADDRESS>:6378 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:03.499 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '08b7646118c97dda89ec59c1dcf91e1de576c6e6', my replication IDs are '7097e29b26d52b108e78bcfc4e0b217ff42d6fdd' and '0000000000000000000000000000000000000000')
1587063:1587087:S 14 Feb 2023 14:54:03.499 * Starting BGSAVE for SYNC with target: disk
1587063:1587087:S 14 Feb 2023 14:54:03.545 * Background saving started by pid 1588467
1587063:1587087:S 14 Feb 2023 14:54:03.757 * Replica <IP_ADDRESS>:6378 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:03.757 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '08b7646118c97dda89ec59c1dcf91e1de576c6e6', my replication IDs are '7097e29b26d52b108e78bcfc4e0b217ff42d6fdd' and '0000000000000000000000000000000000000000')
1587063:1587087:S 14 Feb 2023 14:54:03.757 * Waiting for end of BGSAVE for SYNC
1587063:1587087:S 14 Feb 2023 14:54:03.768 * Replica <IP_ADDRESS>:6378 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:03.768 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '08b7646118c97dda89ec59c1dcf91e1de576c6e6', my replication IDs are '7097e29b26d52b108e78bcfc4e0b217ff42d6fdd' and '0000000000000000000000000000000000000000')
1587063:1587087:S 14 Feb 2023 14:54:03.768 * Waiting for end of BGSAVE for SYNC
1587063:1587087:S 14 Feb 2023 14:54:03.944 * Replica <IP_ADDRESS>:6378 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:03.944 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'f5a360014b192098695f64d176f54316bfcb1521', my replication IDs are '7097e29b26d52b108e78bcfc4e0b217ff42d6fdd' and '0000000000000000000000000000000000000000')
1587063:1587087:S 14 Feb 2023 14:54:03.944 * Waiting for end of BGSAVE for SYNC
1587063:1587087:S 14 Feb 2023 14:54:03.967 * Replica <IP_ADDRESS>:6378 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:03.967 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'f5a360014b192098695f64d176f54316bfcb1521', my replication IDs are '7097e29b26d52b108e78bcfc4e0b217ff42d6fdd' and '0000000000000000000000000000000000000000')
1587063:1587087:S 14 Feb 2023 14:54:03.967 * Waiting for end of BGSAVE for SYNC
1587063:1587087:S 14 Feb 2023 14:54:04.251 * Replica <IP_ADDRESS>:6378 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:04.251 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '08b7646118c97dda89ec59c1dcf91e1de576c6e6', my replication IDs are '7097e29b26d52b108e78bcfc4e0b217ff42d6fdd' and '0000000000000000000000000000000000000000')
1587063:1587087:S 14 Feb 2023 14:54:04.251 * Waiting for end of BGSAVE for SYNC
1587063:1587087:S 14 Feb 2023 14:54:04.758 * Replica <IP_ADDRESS>:6379 asks for synchronization
1587063:1587087:S 14 Feb 2023 14:54:04.758 * Full resync requested by replica <IP_ADDRESS>:6379

i shouldn't use replica-read-only yes with replica-read-only yes

Hi @artarik Yes this was the problem, thank you. Sorry for the delay in updating.

And what's happening on the MASTER <IP_ADDRESS> logs?

Please see below:
849378:807914:C 26 Sep 2023 13:10:01.599 * DB saved on disk
849378:807914:C 26 Sep 2023 13:10:01.630 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:10:01.709 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:13:01.745 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:13:01.778 * Background saving started by pid 849395
849395:807914:C 26 Sep 2023 13:13:02.674 * DB saved on disk
849395:807914:C 26 Sep 2023 13:13:02.705 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:13:02.786 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:15:40.345 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:15:40.378 * Background saving started by pid 849409
849409:807914:C 26 Sep 2023 13:15:41.263 * DB saved on disk
849409:807914:C 26 Sep 2023 13:15:41.295 * RDB: 1 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:15:41.384 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:18:01.437 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:18:01.473 * Background saving started by pid 849425
849425:807914:C 26 Sep 2023 13:18:02.375 * DB saved on disk
849425:807914:C 26 Sep 2023 13:18:02.407 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:18:02.480 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:21:01.765 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:21:01.797 * Background saving started by pid 849444
849444:807914:C 26 Sep 2023 13:21:02.698 * DB saved on disk
849444:807914:C 26 Sep 2023 13:21:02.730 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:21:02.803 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:23:45.084 * Replica <IP_ADDRESS>:6378 asks for synchronization
807900:807914:S 26 Sep 2023 13:23:45.084 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '5a08f8e8954f123f5a13cdc50437b7d0f8fc2cf9', my replication IDs are 'af4297cb9f47db9cb5ef2f4ce172c09dfa948c8a' and '0000000000000000000000000000000000000000')
807900:807914:S 26 Sep 2023 13:23:45.084 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:23:45.119 * Background saving started by pid 849460
849460:807914:C 26 Sep 2023 13:23:46.017 * DB saved on disk
849460:807914:C 26 Sep 2023 13:23:46.050 * RDB: 2 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:23:46.127 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:23:50.979 * Synchronization with replica <IP_ADDRESS>:6378 succeeded
807900:807914:S 26 Sep 2023 13:24:30.771 * Replica <IP_ADDRESS>:6378 asks for synchronization
807900:807914:S 26 Sep 2023 13:24:30.771 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '5a08f8e8954f123f5a13cdc50437b7d0f8fc2cf9', my replication IDs are 'af4297cb9f47db9cb5ef2f4ce172c09dfa948c8a' and '0000000000000000000000000000000000000000')
807900:807914:S 26 Sep 2023 13:24:30.771 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:24:30.806 * Background saving started by pid 849511
849511:807914:C 26 Sep 2023 13:24:31.697 * DB saved on disk
849511:807914:C 26 Sep 2023 13:24:31.731 * RDB: 2 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:24:31.845 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:24:34.970 * Synchronization with replica <IP_ADDRESS>:6378 succeeded
807900:807914:S 26 Sep 2023 13:24:56.007 * Replica <IP_ADDRESS>:6378 asks for synchronization
807900:807914:S 26 Sep 2023 13:24:56.007 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '5a08f8e8954f123f5a13cdc50437b7d0f8fc2cf9', my replication IDs are 'af4297cb9f47db9cb5ef2f4ce172c09dfa948c8a' and '0000000000000000000000000000000000000000')
807900:807914:S 26 Sep 2023 13:24:56.007 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:24:56.041 * Background saving started by pid 849512
849512:807914:C 26 Sep 2023 13:24:56.942 * DB saved on disk
849512:807914:C 26 Sep 2023 13:24:56.975 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:24:57.054 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:25:00.474 * Synchronization with replica <IP_ADDRESS>:6378 succeeded
807900:807914:S 26 Sep 2023 13:25:26.607 * Replica <IP_ADDRESS>:6378 asks for synchronization
807900:807914:S 26 Sep 2023 13:25:26.607 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '5a08f8e8954f123f5a13cdc50437b7d0f8fc2cf9', my replication IDs are 'af4297cb9f47db9cb5ef2f4ce172c09dfa948c8a' and '0000000000000000000000000000000000000000')
807900:807914:S 26 Sep 2023 13:25:26.607 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:25:26.642 * Background saving started by pid 849517
849517:807914:C 26 Sep 2023 13:25:27.551 * DB saved on disk
849517:807914:C 26 Sep 2023 13:25:27.584 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:25:27.669 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:25:32.535 * Synchronization with replica <IP_ADDRESS>:6378 succeeded
807900:807914:S 26 Sep 2023 13:26:58.199 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:26:58.201 # Client id=10 addr=<IP_ADDRESS>:45545 laddr=<IP_ADDRESS>:6379 fd=19 name= age=167017 idle=1 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1560 omem=99967552 tot-mem=99988064 events=rw cmd=replconf user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:26:59.656 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:26:59.656 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:26:59.656 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:26:59.693 * Background saving started by pid 849524
849524:807914:C 26 Sep 2023 13:27:00.607 * DB saved on disk
849524:807914:C 26 Sep 2023 13:27:00.639 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:27:00.721 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:29:00.710 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:29:00.745 * Background saving started by pid 849539
849539:807914:C 26 Sep 2023 13:29:01.646 * DB saved on disk
849539:807914:C 26 Sep 2023 13:29:01.680 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:29:01.754 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:29:38.004 # Client id=15 addr=<IP_ADDRESS>:44531 laddr=<IP_ADDRESS>:6379 fd=19 name= age=159 idle=159 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1703 omem=106827688 tot-mem=106848200 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:29:38.004 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:29:39.769 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:29:39.769 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:29:39.769 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:29:39.805 * Background saving started by pid 849540
849540:807914:C 26 Sep 2023 13:29:40.698 * DB saved on disk
849540:807914:C 26 Sep 2023 13:29:40.732 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:29:40.837 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:32:00.669 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:32:00.705 * Background saving started by pid 849552
849552:807914:C 26 Sep 2023 13:32:01.606 * DB saved on disk
849552:807914:C 26 Sep 2023 13:32:01.641 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:32:01.712 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:32:19.045 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:32:19.053 # Client id=16 addr=<IP_ADDRESS>:40565 laddr=<IP_ADDRESS>:6379 fd=19 name= age=160 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=13969 oll=1725 omem=107545016 tot-mem=107565528 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:32:20.431 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:32:20.431 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:32:20.431 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:32:20.467 * Background saving started by pid 849560
849560:807914:C 26 Sep 2023 13:32:21.351 * DB saved on disk
849560:807914:C 26 Sep 2023 13:32:21.385 * RDB: 6 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:32:21.510 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:35:00.755 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:35:00.790 * Background saving started by pid 849573
807900:807914:S 26 Sep 2023 13:35:01.092 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:35:01.093 # Client id=17 addr=<IP_ADDRESS>:43589 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=161 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=12637 oll=1714 omem=107344048 tot-mem=107364560 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
849573:807914:C 26 Sep 2023 13:35:01.691 * DB saved on disk
849573:807914:C 26 Sep 2023 13:35:01.727 * RDB: 8 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:35:01.797 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:35:02.955 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:35:02.955 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:35:02.956 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:35:02.992 * Background saving started by pid 849574
849574:807914:C 26 Sep 2023 13:35:03.900 * DB saved on disk
849574:807914:C 26 Sep 2023 13:35:03.933 * RDB: 16 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:35:04.014 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:37:45.181 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:37:45.183 # Client id=18 addr=<IP_ADDRESS>:46499 laddr=<IP_ADDRESS>:6379 fd=19 name= age=163 idle=163 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1671 omem=106556584 tot-mem=106577096 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:37:48.267 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:37:48.267 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:37:48.267 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:37:48.306 * Background saving started by pid 849587
849587:807914:C 26 Sep 2023 13:37:49.214 * DB saved on disk
849587:807914:C 26 Sep 2023 13:37:49.249 * RDB: 15 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:37:49.313 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:40:00.861 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:40:00.897 * Background saving started by pid 849600
849600:807914:C 26 Sep 2023 13:40:01.798 * DB saved on disk
849600:807914:C 26 Sep 2023 13:40:01.833 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:40:01.905 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:40:28.093 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:40:28.100 # Client id=19 addr=<IP_ADDRESS>:34583 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1705 omem=107724760 tot-mem=107745272 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:40:30.729 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:40:30.730 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:40:30.730 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:40:30.766 * Background saving started by pid 849605
849605:807914:C 26 Sep 2023 13:40:31.675 * DB saved on disk
849605:807914:C 26 Sep 2023 13:40:31.710 * RDB: 8 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:40:31.829 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:43:01.041 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:43:01.076 * Background saving started by pid 849619
849619:807914:C 26 Sep 2023 13:43:01.969 * DB saved on disk
849619:807914:C 26 Sep 2023 13:43:02.003 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:43:02.084 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:43:09.006 # Client id=20 addr=<IP_ADDRESS>:38589 laddr=<IP_ADDRESS>:6379 fd=19 name= age=159 idle=159 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=11441 oll=1696 omem=106827520 tot-mem=106848032 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:43:09.006 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:43:10.772 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:43:10.772 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:43:10.772 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:43:10.808 * Background saving started by pid 849620
849620:807914:C 26 Sep 2023 13:43:11.707 * DB saved on disk
849620:807914:C 26 Sep 2023 13:43:11.741 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:43:11.858 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:45:53.010 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:45:53.012 # Client id=21 addr=<IP_ADDRESS>:44283 laddr=<IP_ADDRESS>:6379 fd=19 name= age=163 idle=163 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=10295 oll=1687 omem=108027432 tot-mem=108047944 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:45:54.945 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:45:54.946 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:45:54.946 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:45:54.982 * Background saving started by pid 849635
849635:807914:C 26 Sep 2023 13:45:55.871 * DB saved on disk
849635:807914:C 26 Sep 2023 13:45:55.905 * RDB: 11 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:45:55.970 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:48:00.797 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:48:00.831 * Background saving started by pid 849651
849651:807914:C 26 Sep 2023 13:48:01.716 * DB saved on disk
849651:807914:C 26 Sep 2023 13:48:01.751 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:48:01.838 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:48:34.022 # Client id=22 addr=<IP_ADDRESS>:42399 laddr=<IP_ADDRESS>:6379 fd=19 name= age=160 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=15873 oll=1697 omem=107036440 tot-mem=107056952 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:48:34.022 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:48:36.148 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:48:36.148 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:48:36.148 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:48:36.185 * Background saving started by pid 849652
849652:807914:C 26 Sep 2023 13:48:37.088 * DB saved on disk
849652:807914:C 26 Sep 2023 13:48:37.123 * RDB: 6 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:48:37.201 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:51:01.668 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:51:01.703 * Background saving started by pid 849670
849670:807914:C 26 Sep 2023 13:51:02.597 * DB saved on disk
849670:807914:C 26 Sep 2023 13:51:02.631 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:51:02.710 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:51:14.023 # Client id=23 addr=<IP_ADDRESS>:39521 laddr=<IP_ADDRESS>:6379 fd=19 name= age=159 idle=158 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=9222 oll=1691 omem=106008200 tot-mem=106028712 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:51:14.024 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:51:16.414 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:51:16.414 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:51:16.414 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:51:16.451 * Background saving started by pid 849675
849675:807914:C 26 Sep 2023 13:51:17.353 * DB saved on disk
849675:807914:C 26 Sep 2023 13:51:17.387 * RDB: 8 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:51:17.457 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:54:00.061 # Client id=24 addr=<IP_ADDRESS>:33119 laddr=<IP_ADDRESS>:6379 fd=19 name= age=164 idle=164 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1726 omem=109801936 tot-mem=109822448 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:54:00.061 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:54:00.716 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:54:00.754 * Background saving started by pid 849692
849692:807914:C 26 Sep 2023 13:54:01.670 * DB saved on disk
849692:807914:C 26 Sep 2023 13:54:01.706 * RDB: 6 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:54:01.759 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:54:01.874 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:54:01.874 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:54:01.875 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:54:01.912 * Background saving started by pid 849693
849693:807914:C 26 Sep 2023 13:54:02.816 * DB saved on disk
849693:807914:C 26 Sep 2023 13:54:02.851 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:54:02.969 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:56:44.050 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:56:44.052 # Client id=25 addr=<IP_ADDRESS>:38539 laddr=<IP_ADDRESS>:6379 fd=25 name= age=163 idle=163 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1700 omem=108203872 tot-mem=108224384 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:56:47.086 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:56:47.086 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:56:47.086 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:56:47.121 * Background saving started by pid 849703
849703:807914:C 26 Sep 2023 13:56:48.019 * DB saved on disk
849703:807914:C 26 Sep 2023 13:56:48.052 * RDB: 12 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:56:48.177 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:59:03.565 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 13:59:03.601 * Background saving started by pid 849712
849712:807914:C 26 Sep 2023 13:59:04.504 * DB saved on disk
849712:807914:C 26 Sep 2023 13:59:04.539 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:59:04.610 * Background saving terminated with success
807900:807914:S 26 Sep 2023 13:59:27.166 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 13:59:27.174 # Client id=26 addr=<IP_ADDRESS>:36821 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1729 omem=107536920 tot-mem=107557432 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 13:59:28.439 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 13:59:28.439 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 13:59:28.439 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 13:59:28.474 * Background saving started by pid 849713
849713:807914:C 26 Sep 2023 13:59:29.394 * DB saved on disk
849713:807914:C 26 Sep 2023 13:59:29.427 * RDB: 10 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 13:59:29.490 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:02:00.787 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:02:00.820 * Background saving started by pid 849727
849727:807914:C 26 Sep 2023 14:02:01.730 * DB saved on disk
849727:807914:C 26 Sep 2023 14:02:01.767 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:02:01.828 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:02:09.045 # Client id=27 addr=<IP_ADDRESS>:34237 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=161 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1716 omem=108343520 tot-mem=108364032 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:02:09.045 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:02:10.717 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:02:10.717 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:02:10.717 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:02:10.753 * Background saving started by pid 849728
849728:807914:C 26 Sep 2023 14:02:11.642 * DB saved on disk
849728:807914:C 26 Sep 2023 14:02:11.676 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:02:11.800 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:04:54.175 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:04:54.177 # Client id=28 addr=<IP_ADDRESS>:41607 laddr=<IP_ADDRESS>:6379 fd=19 name= age=164 idle=164 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=13174 oll=1717 omem=109641976 tot-mem=109662488 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:04:55.792 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:04:55.792 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:04:55.792 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:04:55.828 * Background saving started by pid 849739
849739:807914:C 26 Sep 2023 14:04:56.714 * DB saved on disk
849739:807914:C 26 Sep 2023 14:04:56.748 * RDB: 2 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:04:56.796 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:07:01.082 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:07:01.118 * Background saving started by pid 849749
849749:807914:C 26 Sep 2023 14:07:02.013 * DB saved on disk
849749:807914:C 26 Sep 2023 14:07:02.048 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:07:02.125 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:07:37.015 # Client id=29 addr=<IP_ADDRESS>:43649 laddr=<IP_ADDRESS>:6379 fd=19 name= age=162 idle=162 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=10977 oll=1704 omem=107708352 tot-mem=107728864 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:07:37.015 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:07:38.699 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:07:38.699 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:07:38.699 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:07:38.736 * Background saving started by pid 849751
849751:807914:C 26 Sep 2023 14:07:39.649 * DB saved on disk
849751:807914:C 26 Sep 2023 14:07:39.681 * RDB: 8 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:07:39.743 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:10:00.975 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:10:01.008 * Background saving started by pid 849760
849760:807914:C 26 Sep 2023 14:10:01.903 * DB saved on disk
849760:807914:C 26 Sep 2023 14:10:01.939 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:10:02.016 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:10:18.034 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:10:18.042 # Client id=30 addr=<IP_ADDRESS>:43169 laddr=<IP_ADDRESS>:6379 fd=19 name= age=160 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1696 omem=106036992 tot-mem=106057504 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:10:19.318 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:10:19.318 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:10:19.318 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:10:19.355 * Background saving started by pid 849761
849761:807914:C 26 Sep 2023 14:10:20.269 * DB saved on disk
849761:807914:C 26 Sep 2023 14:10:20.304 * RDB: 10 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:10:20.362 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:12:58.001 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:12:58.003 # Client id=31 addr=<IP_ADDRESS>:33543 laddr=<IP_ADDRESS>:6379 fd=19 name= age=159 idle=159 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1660 omem=106417056 tot-mem=106437568 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:12:59.969 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:12:59.969 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:12:59.969 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:13:00.008 * Background saving started by pid 849773
849773:807914:C 26 Sep 2023 14:13:00.904 * DB saved on disk
849773:807914:C 26 Sep 2023 14:13:00.938 * RDB: 9 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:13:01.024 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:15:01.392 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:15:01.428 * Background saving started by pid 849780
849780:807914:C 26 Sep 2023 14:15:02.314 * DB saved on disk
849780:807914:C 26 Sep 2023 14:15:02.348 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:15:02.435 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:15:39.001 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:15:39.010 # Client id=32 addr=<IP_ADDRESS>:36661 laddr=<IP_ADDRESS>:6379 fd=19 name= age=160 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1669 omem=104623224 tot-mem=104643736 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:15:41.717 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:15:41.717 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:15:41.717 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:15:41.753 * Background saving started by pid 849783
849783:807914:C 26 Sep 2023 14:15:42.669 * DB saved on disk
849783:807914:C 26 Sep 2023 14:15:42.703 * RDB: 17 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:15:42.762 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:18:00.876 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:18:00.911 * Background saving started by pid 849794
849794:807914:C 26 Sep 2023 14:18:01.808 * DB saved on disk
849794:807914:C 26 Sep 2023 14:18:01.844 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:18:01.917 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:18:22.028 # Client id=33 addr=<IP_ADDRESS>:33417 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=161 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1732 omem=107672160 tot-mem=107692672 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:18:22.028 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:18:23.688 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:18:23.688 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:18:23.688 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:18:23.725 * Background saving started by pid 849795
849795:807914:C 26 Sep 2023 14:18:24.627 * DB saved on disk
849795:807914:C 26 Sep 2023 14:18:24.660 * RDB: 5 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:18:24.782 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:21:01.137 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:21:01.173 * Background saving started by pid 849804
849804:807914:C 26 Sep 2023 14:21:02.074 * DB saved on disk
849804:807914:C 26 Sep 2023 14:21:02.109 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:21:02.183 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:21:04.096 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:21:04.104 # Client id=34 addr=<IP_ADDRESS>:45929 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=161 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1685 omem=105266680 tot-mem=105287192 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:21:06.157 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:21:06.157 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:21:06.157 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:21:06.193 * Background saving started by pid 849805
849805:807914:C 26 Sep 2023 14:21:07.101 * DB saved on disk
849805:807914:C 26 Sep 2023 14:21:07.135 * RDB: 6 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:21:07.228 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:23:47.015 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:23:47.017 # Client id=35 addr=<IP_ADDRESS>:37669 laddr=<IP_ADDRESS>:6379 fd=19 name= age=162 idle=161 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1691 omem=107568776 tot-mem=107589288 events=rw cmd=psync user=default redir=-1 closed for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:23:48.520 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:23:48.520 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:23:48.520 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:23:48.557 * Background saving started by pid 849815
849815:807914:C 26 Sep 2023 14:23:49.476 * DB saved on disk
849815:807914:C 26 Sep 2023 14:23:49.510 * RDB: 8 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:23:49.565 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:26:00.927 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:26:00.963 * Background saving started by pid 849821
849821:807914:C 26 Sep 2023 14:26:01.858 * DB saved on disk
849821:807914:C 26 Sep 2023 14:26:01.894 * RDB: 4 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:26:01.970 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:26:29.016 # Client id=36 addr=<IP_ADDRESS>:44821 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=161 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1727 omem=108700136 tot-mem=108720648 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:26:29.016 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:26:31.063 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:26:31.063 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:26:31.063 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:26:31.099 * Background saving started by pid 849823
849823:807914:C 26 Sep 2023 14:26:31.997 * DB saved on disk
849823:807914:C 26 Sep 2023 14:26:32.030 * RDB: 12 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:26:32.119 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:29:00.895 * 10000 changes in 60 seconds. Saving...
807900:807914:S 26 Sep 2023 14:29:00.930 * Background saving started by pid 849832
849832:807914:C 26 Sep 2023 14:29:01.823 * DB saved on disk
849832:807914:C 26 Sep 2023 14:29:01.858 * RDB: 3 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:29:01.937 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:29:11.123 # Client id=37 addr=<IP_ADDRESS>:32841 laddr=<IP_ADDRESS>:6379 fd=19 name= age=161 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=8104 oll=1704 omem=106786752 tot-mem=106807264 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:29:11.124 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:29:13.508 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:29:13.508 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:29:13.508 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:29:13.544 * Background saving started by pid 849833
849833:807914:C 26 Sep 2023 14:29:14.452 * DB saved on disk
849833:807914:C 26 Sep 2023 14:29:14.485 * RDB: 19 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:29:14.551 * Background saving terminated with success
807900:807914:S 26 Sep 2023 14:31:53.137 # Client id=38 addr=<IP_ADDRESS>:39311 laddr=<IP_ADDRESS>:6379 fd=19 name= age=160 idle=160 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=1702 omem=107794320 tot-mem=107814832 events=rw cmd=psync user=default redir=-1 scheduled to be closed ASAP for overcoming of output buffer limits.
807900:807914:S 26 Sep 2023 14:31:53.138 # Connection with replica <IP_ADDRESS>:6379 lost.
807900:807914:S 26 Sep 2023 14:31:56.946 * Replica <IP_ADDRESS>:6379 asks for synchronization
807900:807914:S 26 Sep 2023 14:31:56.946 * Full resync requested by replica <IP_ADDRESS>:6379
807900:807914:S 26 Sep 2023 14:31:56.946 * Starting BGSAVE for SYNC with target: disk
807900:807914:S 26 Sep 2023 14:31:56.982 * Background saving started by pid 849843
849843:807914:C 26 Sep 2023 14:31:57.894 * DB saved on disk
849843:807914:C 26 Sep 2023 14:31:57.929 * RDB: 14 MB of memory used by copy-on-write
807900:807914:S 26 Sep 2023 14:31:58.037 * Background saving terminated with success


Fixes group by select

[x] Changes have been thoroughly tested to not break existing functionality.
[x] New functionality has been documented or existing documentation has been updated to reflect changes.
[x] Visual changes are explained in the PR description using a screenshot/recording of before and after.

Before:

After:

Tables package design revamp is still work-in-progress, but thanks for attempting a fix.
I've fixed this in https://github.com/filamentphp/filament/commit/33fc13604a5fa64876544d51d02130d88d306706.


libomp: xgboost incorrect LC_RPATH referenced in libxgboost.dylib

Upon installing xgboost (2.1.2) with pip on macOS (15.0.1) I noticed that there was an error related to not finding libomp once installed. In the installed libxgboost.dylib the rcpath references an absolute 'homebrew' directory (I don't use homebrew).
% otool -l /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/xgboost/lib/libxgboost.dylib
Load command 15
          cmd LC_RPATH
      cmdsize 48
         path /opt/homebrew/opt/libomp/lib (offset 12)

It should likely be changed to use: @rpath/libomp unless you expect anyone who doesn't use homebrew to fix the hardcoded path anytime they install xgboost with pip.

@Ubiquitous Thank you for opening an issue. Would you like to help fix it? We are indeed having a lot of headaches with macos distribution around openmp, your expertise is appreciated.

We merged #10440 to patch libxgboost.dylib so that it depends on @rpath/libomp.dylib, by running
otool install_name_tool -change /opt/homebrew/opt/libomp/lib/libomp.dylib<EMAIL_ADDRESS>libxgboost.dylib

It looks like we need to run additional command(s) to patch the rcpath as well.

@Ubiquitous Can you try running the following command and see if that fixes the issue?
install_name_tool -add_rpath "@rpath/libomp" /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/xgboost/lib/libxgboost.dylib

I also want to hear from @jameslamb about how LightGBM solved this issue.

It should likely be changed to use: @rpath/libomp unless you expect anyone who doesn't use homebrew to fix the hardcoded path anytime they install xgboost with pip.

This doesn't sound quite right to me. Having an RPATH pointing to Homebrew's preferred location is just a hint to the loader. If you don't have OpenMP installed via Homebrew, then there shouldn't be anything found at that path, and the loader should precede to search standard system paths like /usr/lib.
Before we go any further... @Ubiquitous can you please share precisely what problem you encountered? How are you getting OpenMP and where is it installed?
You just mentioned "an error" and then prescribed a solution... but the solution will depend on the specific problem you faced.
Important to note that the install name for libxgboost.dylib's OpenMP dependency is @rpath/libomp.dylib (as @hcho3 alluded to in https://github.com/dmlc/xgboost/issues/10946#issuecomment-2449275846), so it's not true that using Homebrew is absolutely required.
mkdir -p ./delete-me
pip download \
	-d ./delete-me \
	--no-deps \
	--prefer-binary \
	'xgboost==2.1.2'

cd ./delete-me
unzip ./xgboost*.whl

otool -l xgboost/lib/libxgboost.dylib

Excerpt from that:
Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name @rpath/libomp.dylib (offset 24)
   time stamp 2 Wed Dec 31 18:00:02 1969
      current version 5.0.0
compatibility version 5.0.0
...
Load command 15
          cmd LC_RPATH
      cmdsize 48
         path /opt/homebrew/opt/libomp/lib (offset 12)

And output of otool -L ./xgboost/lib/libxgboost.dylib
./xgboost/lib/libxgboost.dylib:
        @rpath/libxgboost.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1700.255.5)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)

@jameslamb, I apologize for not being more clear; I installed the libomp via MacPorts, succeeded by pip install xgboost. An error came back after import xgboost threw and exception: libomp.dylib no such file. The exact error is shown below and none of the locations searched is where MacPorts installs libomp.dylib.
% pip install xgboost
...
Successfully installed xgboost-2.1.2

% python
>>> import xgboost as xgb

Error message(s): ["dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/xgboost/lib/libxgboost.dylib, 0x0006): Library not loaded: @rpath/libomp.dylib\n
Referenced from: <F2F42313-BF4F-3B95-A853-AE1DE94D4C87> /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/xgboost/lib/libxgboost.dylib\n
Reason: tried: '/opt/homebrew/opt/libomp/lib/libomp.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libomp/lib/libomp.dylib' (no such file), '/opt/homebrew/opt/libomp/lib/libomp.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libomp/lib/libomp.dylib' (no such file)"]

I used otool to check the paths of libxgboost.dylib:
% otool -l /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/xgboost/lib/libxgboost.dylib

...
Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name @rpath/libomp.dylib (offset 24)
   time stamp 2 Wed Dec 31 17:00:02 1969
      current version 5.0.0
compatibility version 5.0.0
Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name /usr/lib/libc++.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 17:00:02 1969
      current version 1700.255.5
compatibility version 1.0.0
Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Wed Dec 31 17:00:02 1969
      current version 1345.120.2
compatibility version 1.0.0
Load command 15
          cmd LC_RPATH
      cmdsize 48
         path /opt/homebrew/opt/libomp/lib (offset 12)
...

I used install_name_tool to change the path of Load command 15:
% sudo install_name_tool -rpath /opt/homebrew/opt/libomp/lib /opt/local/lib/libomp /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/xgboost/lib/libxgboost.dylib

xgboost worked fine after that.

I searched here in the repo for references to homebrew, which found 12 files, although it's unclear exactly where the path is getting set when pip builds libxgboost.dylib
My recommendation would likely be to create a different build script that takes into account possible other locations where libomp.dylib might be installed and set the @rpath that way. Possible issues with this approach is that there could be more than one version or installed in a location that's uncommon.
#!/bin/bash

# Common base paths where libomp might be installed
BASE_PATHS=(
    "/opt/local/lib/libomp"           # MacPorts
    "/opt/homebrew/opt/libomp/lib"    # Homebrew Apple Silicon
    "/usr/local/opt/libomp/lib"       # Homebrew Intel
    "/usr/local/lib/libomp"           # Custom install
    "/usr/lib/libomp"                 # System
)

# Check each base path for libomp.dylib
for base in "${BASE_PATHS[@]}"; do
    if [ -f "$base/libomp.dylib" ]; then
        echo "Found: $base/libomp.dylib"
        exit 0
    fi
done

# If not found in common paths, do a restricted but deeper check
for dir in /opt /usr/local; do
    find "$dir" -name "libomp.dylib" 2>/dev/null
done

Since I'm running MacPorts the path where libomp.dylib resides is /opt/local/lib/libomp.
I can certainly help you resolve the issue, although there's multiple ways to attack here. Having what appears to be an exclusive dependency on Homebrew is likely the wrong approach.

Thanks for that detail... it makes the problem and relative preference for solutions much clearer.
It's not quite accurate to frame this problem as XGBoost having an "exclusive dependency on Homebrew". I strongly suspect that if you set environment variable LD_LIBRARY_PATH=/opt/local/lib/libomp or symlinked the macports install of OpenMP into a system directory like /usr/local/lib, import xgboost would find that library without any modifications to its binary.
But anyway... @hcho3 I think xgboost should add something like https://github.com/microsoft/LightGBM/pull/6489, to take on an additional RPATH of /opt/local/lib/libomp for macOS builds. That'd allow libomp.dylib installed via macPorts to be found at runtime.
No shell script like https://github.com/dmlc/xgboost/issues/10946#issuecomment-2453327925 (or equivalent code in any other language) should be required... just adding another RPATH entry here: https://github.com/dmlc/xgboost/blob/c502bb894cea4cc4304a2b2b97438741ea6574a9/cmake/FindOpenMPMacOS.cmake#L121
How LightGBM does this: https://github.com/microsoft/LightGBM/blob/13f2e92bb0ac64f94d9b5016a33b5c34d2134204/CMakeLists.txt#L777-L782

@jameslamb You're welcome, and thank you for your attention on this issue.
Why though does the LC_RPATH get set to /opt/homebrew/opt/libomp/lib? Sure, I can set the environment variable or symlink as you said, although the error seemed to indicate libxgboost.dylib was relying on the homebrew path to find libomp.dylib.

@Ubiquitous We can do what LightGBM does, which is to specify both /opt/homebrew/opt/libomp/lib and /opt/local/lib/libomp as candidates for the rpath. I will prepare a pull request.

Why though does the LC_RPATH get set to /opt/homebrew/opt/libomp/lib?

I think you are maybe misunderstanding how LC_RPATH works. You can provide multiple such paths and the loader will search them in order. Instead of saying "set to", it would be more accurate to say "has one entry pointing to". On your system, where /opt/homebrew/opt/libomp/lib does not exist, libxgboost.dylib having an RPATH entry pointing at that Homebrew-specific directory is not a problem.
And xgboost provides that path as a hint because it uses Homebrew to provide OpenMP in its wheel builds,
https://github.com/dmlc/xgboost/blob/3a9ce48573b7209716f81c4d2093bfaba95fdcd6/.github/workflows/python_wheels.yml#L33-L34
and because its docs recommend that users install OpenMP with homebrew.
https://github.com/dmlc/xgboost/blob/3a9ce48573b7209716f81c4d2093bfaba95fdcd6/doc/install.rst?plain=1#L136-L140
I'd support libxgboost.dylib picking up an additional RPATH entry suggesting that the loader should look wherever macports puts libomp.dylib (/opt/local/lib/libomp), as we do in lightgbm and as I linked above.

@Ubiquitous We can do what LightGBM does, which is to specify both /opt/homebrew/opt/libomp/lib and /opt/local/lib/libomp as candidates for the rpath. I will prepare a pull request.

Yes, that would work fine, thank you.

Why though does the LC_RPATH get set to /opt/homebrew/opt/libomp/lib?

I think you are maybe misunderstanding how LC_RPATH works. You can provide multiple such paths and the loader will search them in order. Instead of saying "set to", it would be more accurate to say "has one entry pointing to". On your system, where /opt/homebrew/opt/libomp/lib does not exist, libxgboost.dylib having an RPATH entry pointing at that Homebrew-specific directory is not a problem.
And xgboost provides that path as a hint because it uses Homebrew to provide OpenMP in its wheel builds,
https://github.com/dmlc/xgboost/blob/3a9ce48573b7209716f81c4d2093bfaba95fdcd6/.github/workflows/python_wheels.yml#L33-L34
and because its docs recommend that users install OpenMP with homebrew.
https://github.com/dmlc/xgboost/blob/3a9ce48573b7209716f81c4d2093bfaba95fdcd6/doc/install.rst?plain=1#L136-L140
I'd support libxgboost.dylib picking up an additional RPATH entry suggesting that the loader should look wherever macports puts libomp.dylib (/opt/local/lib/libomp), as we do in lightgbm and as I linked above.

Including the additional path(s) would be great.I wasn't misunderstanding how rpath works, it just came across as if homebrew was all that was supported since it was the only rpath included. One thing to note is the homebrew path for apple intel might differ from apple silicon, although I can't confirm that, so you might want to include both of those as well perhaps ~ tc.


to add open source apps made using flutter

Platypus Crypto
(https://github.com/Blakexx/CryptoTracker)
Platypus Crypto is an ad-free cross-platform robust solution for tracking cryptocurrency assets.

can u plas assign me this issue


Add Random

Add random quote function, shows random dude with quote

Come back with a description

You did the changelog wrong, newest is top


Overwrite protection when generating keys and storing in a vault

The keys in a vault can be overwritten if new keys are generated with the same name
Tessera should check if keys already exist with the provided name and if so, provide a prompt to the user confirming if they want to overwrite these values.

Additionally, Hashicorp key generation currently sets the key names as publicKey and privateKey.  Providing the ability to set custom names would also help prevent keys from being overwritten.

This issue has been closed as an alternative resolution was used.  With #565 and #574, Tessera can retrieve the previous versions of a secret stored in an Azure or Hashicorp vault, thereby preventing a complete overwrite of the values stored in the vault.


KTOR-1909 add links to examples

Added links to runnable code examples from corresponding topics, an example:

LGTM. Just one question. Microformat is a specific tag available or can we customise the name?

LGTM. Just one question. Microformat is a specific tag available or can we customise the name?

It's a specific tag


Use DepotDownloader to reduce download size

As you know, the game files used by the client are also downloaded when running a CS2 server, rather than just files dedicated to that purpose. However, you can use a third party application called DepotDownloader to ignore certain files using the -filelist and -depot parameters, therefore cutting down on download size. DepotDownloader can also cache Steam Guard credentials.
The lists of files can be found here:

Common asset files (including maps): https://steamdb.info/depot/2347770/
Linux binaries: https://steamdb.info/depot/2347773/
Windows binaries: https://steamdb.info/depot/2347771/

The asset files found in these depots can be inspected using Source 2 Viewer (aka ValveResourceFormat), which may be able to identify files not needed for DS operation.
Thanks,
pointy

Cool idea!
The challenge will be figuring out which files can be done away with.
Currently, the best way to get the container to start quickly is to attach a persistent volume so that you only need to download updates on container start:
-v /var/lib/docker/cs2-data:/home/steam/cs2-dedicated/


Dependabot can't parse pyproject.toml with inline comments in dependencies section

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
pip
Package manager version
No response
Language version
3.10.13
Manifest location and content before the Dependabot update
No response
dependabot.yml content
No response
Updated dependency
No response
What you expected to see, versus what you actually saw
Hi! Dependabot can't parse pyproject.toml with inline comments in dependencies section. I think there is a problem with regexes. I guess that it might be caused by the following PR:
https://github.com/dependabot/dependabot-core/pull/8190/files
[tool.poetry.dependencies]  # Main (runtime) dependencies
python = "~3.10"
...

[tool.poetry.group.dev.dependencies]  # Development (local) dependencies
black = "^23.9.1"
...

But it works with:
[tool.poetry.dependencies]
# Main (runtime) dependencies
python = "~3.10"
...

[tool.poetry.group.dev.dependencies]
# Development (local) dependencies
black = "^23.9.1"
...

Likewise, it works without comments:
[tool.poetry.dependencies]
python = "~3.10"
...

[tool.poetry.group.dev.dependencies]
black = "^23.9.1"
...

We are facing RuntimeError while trying to update dependencies using Dependabot due to this issue:
updater | INFO <job_747959705> Updating kombu from 5.3.2 to 5.3.3
updater | INFO <job_747959705> Sending event {eventId} to Sentry
updater | ERROR <job_747959705> Error processing kombu (RuntimeError)
updater | ERROR <job_747959705> Content did not change!
updater | ERROR <job_747959705> /home/dependabot/python/lib/dependabot/python/file_updater/poetry_file_updater.rb:74:in `updated_pyproject_content'
updater | ERROR <job_747959705> /home/dependabot/python/lib/dependabot/python/file_updater/poetry_file_updater.rb:48:in `fetch_updated_dependency_files'
updater | ERROR <job_747959705> /home/dependabot/python/lib/dependabot/python/file_updater/poetry_file_updater.rb:31:in `updated_dependency_files'
updater | ERROR <job_747959705> /home/dependabot/python/lib/dependabot/python/file_updater.rb:101:in `updated_poetry_based_files'
updater | ERROR <job_747959705> /home/dependabot/python/lib/dependabot/python/file_updater.rb:34:in `updated_dependency_files'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:87:in `generate_dependency_files'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:37:in `run'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:26:in `create_from'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:128:in `check_and_create_pull_request'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:60:in `check_and_create_pr_with_error_handling'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `block in perform'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `each'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `perform'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:64:in `run'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:39:in `perform_job'
updater | ERROR <job_747959705> /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:53:in `run'

Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

Thanks for the report!
This is indeed a regression caused by the patch that you mentioned. Would you be able to create a PR to fix it?

@deivid-rodriguez I'll prepare a PR to fix the issue 👍

Hi @deivid-rodriguez! Could you please review my PR regarding the aforementioned issue when you have time?:
https://github.com/dependabot/dependabot-core/pull/8423


feat: add function in namespace snippet

Summary by Sourcery
Add functionality to support namespace-specific function documentation by introducing doxyNamespaceFunction in finder.py and updating generatorSnippets.py to handle this new feature. Update the documentation to reflect these changes.
New Features:

Introduce a new function doxyNamespaceFunction in the finder.py to locate functions within a specific namespace.

Enhancements:

Add support for namespace.function in generatorSnippets.py to handle namespace-specific function documentation.

Documentation:

Update functions.md to include documentation for the new doxy.<project>.namespace.function tag, explaining its usage and parameters.

Hello, sorry I executed mkdocs serve and this is what I have on my PR after some bugfix:

Thank you for the help, merged in https://pypi.org/project/mkdoxy/1.2.6/


chore(main): release 0.1.1

:robot: I have created a release beep boop
0.1.1 (2023-05-10)
Docs

update AdGuard Home and Cloudflare WARP Rules in README.md (c31776f)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/cloverdefa/Rule-Sets/releases/tag/v0.1.1 :sunflower:


FINERACT-1958: Rework down-payment calculation

Description
2 tests got disabled:
LoanAccountPaymentAllocationWithOverlappingDownPaymentInstallmentTest

loanAccountWithEnableDownPaymentAndDisableAutoRepaymentForDownPaymentWithOverlappingInstallmentPaymentAllocationTest()
loanAccountWithEnableDownPaymentAndEnableAutoRepaymentForDownPaymentWithOverlappingInstallmentPaymentAllocationTest()

A follow up PR will fix them!
Describe the changes made and why they were made.
Ignore if these details are present on the associated Apache Fineract JIRA ticket.
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[ ] Write the commit message as per https://github.com/apache/fineract/#pull-requests

[ ] Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

[ ] Create/update unit or integration tests for verifying the changes made.

[ ] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.

[ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes

[ ] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

1.Not clear how we are handling overlapping downpayment installments during generate flow. 2.Not clear how we are handling Number of Repayments check during schedule generation.

It does not. Please have a follow up PR to handle them properly
The number of repayments does not contain the down-payment installment anymore. We need to only set how many regular installments we want.


UEFI SB release

Gather all tests that were implemented while working on UEFI Secure Boot

Results on QEMU after latest rebase on develop below. QEMU started with DRIVE_PATH=./qemu-data/dts-base-sb-image-genericx86-64.wic ./scripts/ci/qemu-run.sh graphic os command, dts-base-sb-image-genericx86-64.wic is decompressed DTS image built by using https://github.com/Dasharo/meta-dts/blob/main/kas-uefi-sb.yml.
λ robot -b file.txt -L TRACE -v ansible_config:yes -v rte_ip:<IP_ADDRESS> -v snipeit:no -v config:qemu dasharo-security/secure-boot.robot
==============================================================================
Secure-Boot
==============================================================================
SBO001.001 Check Secure Boot default state (firmware) :: This test... | PASS |
------------------------------------------------------------------------------
SBO002.001 UEFI Secure Boot (Ubuntu 22.04) :: This test verifies t... | PASS |
------------------------------------------------------------------------------
SBO002.002 UEFI Secure Boot (Windows 11) :: This test verifies tha... | SKIP |
SBO002.002 not supported
------------------------------------------------------------------------------
SBO003.001 Attempt to boot file with the correct key from Shell (f... | PASS |
------------------------------------------------------------------------------
SBO004.001 Attempt to boot file without the key from Shell (firmwa... | PASS |
------------------------------------------------------------------------------
SBO005.001 Attempt to boot file with the wrong-signed key from She... | PASS |
------------------------------------------------------------------------------
SBO006.001 Reset Secure Boot Keys option availability (firmware) :... | PASS |
------------------------------------------------------------------------------
SBO007.001 Attempt to boot the file after restoring keys to defaul... | PASS |
------------------------------------------------------------------------------
SBO008.001 Attempt to enroll the key in the incorrect format (firm... | PASS |
------------------------------------------------------------------------------
SBO009.001 Attempt to boot file signed for intermediate certificat... | PASS |
------------------------------------------------------------------------------
SBO010.001 Check support for rsa2k signed certificates :: PEM gene... | PASS |
------------------------------------------------------------------------------
SBO010.002 Check support for rsa3k signed certificates :: PEM gene... | PASS |
------------------------------------------------------------------------------
SBO010.003 Check support for rsa4k signed certificates :: PEM gene... | PASS |
------------------------------------------------------------------------------
SBO010.004 Check support for ecdsa256 signed certificates :: PEM g... | FAIL |
'
Command Error Status: Access Denied
FS0:\>' does not contain 'hello, world!'
------------------------------------------------------------------------------
SBO010.005 Check support for ecdsa384 signed certificates :: PEM g... | FAIL |
'
Command Error Status: Access Denied
FS0:\>' does not contain 'hello, world!'
------------------------------------------------------------------------------
SBO010.006 Check support for ecdsa521 signed certificates :: PEM g... | FAIL |
'
Command Error Status: Access Denied
FS0:\>' does not contain 'hello, world!'
------------------------------------------------------------------------------
SBO011.001 Attempt to enroll expired certificate and boot signed i... | FAIL |
'
Hello, world!
FS0:\>' does not contain any of 'Access Denied'
------------------------------------------------------------------------------
SBO012.001 Boot OS Signed And Enrolled From Inside System (Ubuntu ... | PASS |
------------------------------------------------------------------------------
SBO013.001 Check automatic certificate provisioning :: This test v... | PASS |
------------------------------------------------------------------------------
SBO013.002 Check automatic certificate provisioning KEK certificat... | PASS |
------------------------------------------------------------------------------
SBO014.001 Enroll certificates using sbctl :: This test erases Sec... | PASS |
------------------------------------------------------------------------------
SBO015.001 Attempt to enroll the key in the incorrect format (OS) ... | PASS |
------------------------------------------------------------------------------
Secure-Boot                                                           | FAIL |
22 tests, 17 passed, 4 failed, 1 skipped
==============================================================================
Debug:   /home/tzyjewski/files/open-source-firmware-validation/file.txt
Output:  /home/tzyjewski/files/open-source-firmware-validation/output.xml
Log:     /home/tzyjewski/files/open-source-firmware-validation/log.html
Report:  /home/tzyjewski/files/open-source-firmware-validation/report.html

ecdsa tests fails as BIOS does not accepts ecdsa-based certs
test with expired cert fails, as BIOS can still execute efi file signed with expired cert

Latest results on msi pro z690-a ddr5
results.tar.gz
Sometimes suite teardown fails (or any other test) because test e.g. goes into HDD Security Configuration instead of Secure Boot Configuration. Looks like it sometimes slip one step.
results-teardown.tar.gz

@macpijan I responded in all threads. I think that @m-iwanicki @PLangowski @DaniilKl might help if there will be additional questions.


[SDK] Fix CanaryStrategy. Remove isWaiting()

Can you either link a JIRA or provide a description in this PR?

Problem: After first continue request, first step should start in Canary. It was not starting any step till all required continues are received.
See commit descriptions:
Fix Canary Strategy: return phase not interrupted, after first continue, till proceeded step is started.
Remove isWaiting(). isWaiting() != isInterrupted(), WAITING is a special status, only used to show/print plan/phase/step details.

LGTM


🚧 Dev ➾ Provide a Means for Users to Clear Docker Images and Transient State/cache taq clean cache

u### 🔗 Epic|Feature Link
No response
🚥 Definition of Done

[ ] 🎯 Planning and Design
[ ] 🏎 Dev Implementation (PR merged)
[ ] ✍ Release Notes Added
[ ] 🏆 Product Acceptance

✅ To Do
No response
⚖ Acceptance Criteria
✨ Functional:

[ ] A task is provided that can remove Docker images related to Taqueria
[ ] The user is shown a list of what will be removed before any removal
[ ] Look for images related to Taqueria that weren't installed by any plugins (Ligo for example)
[ ] The task resets the project's transient state

📐 Non-Functional:

[ ] ...

🔭 Scope
🙅♂ Out of Scope:

Granular selection of what to delete

🧰 Work Description
This ticket covers the creation of a new task that can clear out the project's transient state and remove all docker images that Taqueria uses
🦄 Sizing
2
Code of Conduct

[X] I agree to follow this project's Code of Conduct

@mweichert @jchenche , can you please provide an estimate for this?


Setting the caching behavior of the framebuffer to write combining results in significantly higher throughput.
The framebuffer should either be setup to use write combining in the bootloader,
or it should be mentioned in the readme/migration guides.
(It took me quite some time to figure out that that was my bottle neck)

Yes, setting the cache to write combining improvies the performance considerably. Mentioning it in the README and migration guide is a good idea!
I also thought about setting it by default for the framebuffer memory region, but I'm not sure how yet. The PAT seems like the more modern approach, but it requires modifying the default config to enable write-combining caching, which might lead to issues if the kernel changes it later. MTRRs seems to be the legacy way to do it, but I haven't had time to take a coser look.
What approach did you use for your kernel?

I changed the PAT entry for write_through + cache_disabled (index 3)  to write combining; And changed the page table flags of the framebuffer to use this entry. This is no option for the bootloader since the user doesn't expect this behavior.
A better approach would be to make use of the third bit to address the pat.
This, as far as I know, requires the framebuffer to be mapped in huge pages.


Custom problem matcher "kind": "file" doesn't matches

For the following console output
[ i ] PROCESS SUITES/TESTS RESULTS ...
-------------------------------------------------------------------------------
 Suite: inline_files_list (1 tests)
-------------------------------------------------------------------------------
 failed: 1
-------------------------------------------------------------------------------
| 00:00:05 |    failed | w/o browser@Manjaro Linux | nogui/fs_sands_profile.rb
-------------------------------------------------------------------------------
 Suite start time  : 12:41:09
 Suite end time    : 12:41:20
 Suite elapsed time: 00:00:11
-------------------------------------------------------------------------------
[ ! ] Failed tests list was stored in 'inline_files_list_failed' suite.

custom problem matcher works with following pattern matcher
        "pattern": [
          {
            "regexp": "^(\\|.*failed\\s+\\|.*\\|(.*))$",
            "file": 2,
            "location": 0,
            "message": 1
          }
        ]

but I dont need location so I read in documentation that there is "kind": "file" field to avoid location to be in problem so I changed matcher to
        "pattern": [
          {
            "kind": "file",
            "regexp": "^(\\|.*failed\\s+\\|.*\\|(.*))$",
            "file": 2,
            "message": 1
          }
        ]

but this doesn't match problem with the same console output.
I would expect it is matched as error
VSCode Version:
Version 1.22.1
Commit 950b8b0d37a9b7061b6f0d291837ccc4015f5ecd
Date 2018-04-06T00:24:49.616Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
OS Version:
System:    Host: DzirT-LT Kernel: 4.9.92-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.12.3
Distro: Manjaro Linux 17.1.7 Hakoila
Machine:   Type: Laptop System: Dell product: XPS 15 9550 v: N/A serial: N/A

Fixed for next build


Pretrained model

can you please share the pretrained model?

Sure, but it is quite large.
On Thu, Sep 28, 2017, 10:01 Zumbalamambo<EMAIL_ADDRESS>wrote:

can you please share the pretrained model?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/HongyangGao/PixelDCN/issues/44, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGcr8seriF2cXUNzQh6Yp6RCMtXWgKmks5sm9D7gaJpZM4Pnldg
.

--
Hongyang

Thank you so much.. it will save my life..

Is that so important?
On Thu, Sep 28, 2017, 10:43 Zumbalamambo<EMAIL_ADDRESS>wrote:

Thank you so much.. it will save my life..
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/HongyangGao/PixelDCN/issues/44#issuecomment-332911355,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGcrxs9rUtaUkz7ujISPx0sD4dE6WMPks5sm9qsgaJpZM4Pnldg
.

--
Hongyang

yes...please...

Im working in cpu... I dont have gpu... sharing this will be useful  .... :)