text:
Turbo caches incomplete results.

Verify canary release

[X] I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue
https://github.com/laat/turbo-repo-cache-repro
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Which canary version will you have in your reproduction?
1.11.1
Describe the Bug
when running concurrent linting and build, if the linting fails the build is killed and its outputs are cached
Expected Behavior
it should not store partial/incomplete outputs
To Reproduce
I created a repro
clone it and:

pnpm install
pnpm turbo build lint (expected to fail on lint, before build completes)
pnpm turbo build

Expected result after final step:
apps/docs/dist is created with content.
Actual result:
apps/docs/dist does not exist, but has this output with successful exit code:
docs:build: cache hit, replaying logs d7849613a3a4e98d
docs:build:
docs:build: > docs@1.0.0 build /Users/laat/git/turborepo-repro/apps/docs
docs:build: > node build.js
docs:build:

 Tasks:    1 successful, 1 total
Cached:    1 cached, 1 total
  Time:    58ms >>> FULL TURBO

Additional context
works as expected in 1.10.16

I've been testing your repro and have been unable to get the result you describe.
A few pieces of information that might help:

Can you share the tar file in the cache? It should be at node_modules/.cache/turbo/2f2ac4c8cf9904ef.tar.zst
Could you include the logs from the first pnpm turbo build lint run with a clear cache? (rm -r node_modules/.cache/turbo)

$ pnpm turbo daemon clean
Done

$ git clean -xfd
Removing node_modules/

$ pnpm install
Scope: all 3 workspace projects
Lockfile is up to date, resolution step is skipped
Packages: +2
++
Progress: resolved 2, reused 2, downloaded 0, added 2, done

devDependencies:
+ turbo 1.11.1

The dependency was already listed in devDependencies.
If you want to make it a prod dependency, then move it manually.

Done in 309ms

$ pnpm turbo build lint
• Packages in scope: docs, web
• Running build, lint in 2 packages
• Remote caching disabled
docs:build: cache miss, executing 2f2ac4c8cf9904ef
web:lint: cache miss, executing 07a271d5d104cda2
docs:build:
docs:build: > docs@1.0.0 build /Users/n637831/git/turborepo-repro/apps/docs
docs:build: > node build.js
docs:build:
web:lint:
web:lint: > web@1.0.0 lint /Users/n637831/git/turborepo-repro/apps/web
web:lint: > node lint.js
web:lint:
web:lint: Linting failed
web:lint:  ELIFECYCLE  Command failed with exit code 1.
web:lint:  WARN   Local package.json exists, but node_modules missing, did you mean to install?
web:lint: ERROR: command finished with error: command (/Users/n637831/git/turborepo-repro/apps/web) /Users/n637831/Library/pnpm/pnpm run lint exited (1)
web#lint: command (/Users/n637831/git/turborepo-repro/apps/web) /Users/n637831/Library/pnpm/pnpm run lint exited (1)

 Tasks:    1 successful, 2 total
Cached:    0 cached, 2 total
  Time:    899ms
Failed:    web#lint

 ERROR  run failed: command  exited (1)

$ pnpm turbo build
• Packages in scope: docs, web
• Running build in 2 packages
• Remote caching disabled
docs:build: cache hit, replaying logs 2f2ac4c8cf9904ef
docs:build:
docs:build: > docs@1.0.0 build /Users/n637831/git/turborepo-repro/apps/docs
docs:build: > node build.js
docs:build:

 Tasks:    1 successful, 1 total
Cached:    1 cached, 1 total
  Time:    55ms >>> FULL TURBO

Cache files:
https://github.com/laat/turbo-repo-cache-repro/tree/cache/node_modules/.cache/turbo

and a CI job with the same behavior:
https://github.com/laat/turbo-repo-cache-repro/pull/1

Can you quick check if using --go-fallback with your turbo commands results in the correct behavior?

Could it be the way pnpm handles SIGINT? https://github.com/pnpm/pnpm/issues/7374
pnpm seems to exit with exit-code 0 when it's receives SIGINT...

It could be?
It's definiteness something to do with signal handling since it appears that when we're shutting down the docs#build task by sending it a SIGINT for some reason it's taking the path of a process that exited with 0. Either way, this is a bug on our part for not handling it.

Okay, I've been able to reproduce the behavior you're seeing by modifying turbo with the following change:
visitor.rs
@@ -814,7 +814,7 @@ impl ExecContext {
         };

         match exit_status {
-            ChildExit::Finished(Some(0)) => {
+            ChildExit::Finished(Some(0)) | ChildExit::Finished(None) => {

So I'm guessing that somehow when we're sending the SIGINT to the process running pnpm run build for docs we're getting back an exit code of 0. Will compare our Go/Rust implementations of sending these signals to see if there are any minor differences that could cause this.
I'm still unsure what could be different from my machines and your machine/Github Actions where I can't get the same behavior out of the box.

My guess is that we are entering different listeners in pnpm somehow. It's rather strange.
There are two listeners on subprocess termination in pnpm:
https://github.com/pnpm/npm-lifecycle/blob/e3766d18f13b75f31ab162dbef8e7167cda3afe7/index.js#L279-L290
and
https://github.com/pnpm/npm-lifecycle/blob/e3766d18f13b75f31ab162dbef8e7167cda3afe7/index.js#L331-L333
where both the github action and me seem to enter the exit listener, while you are entering the close listener. I do not have access the machine where this issue occurs until monday to debug further.

what version of pnpm do you use?
I'm seeing the error with pnpm > 8.10, but not in pnpm@8.9.2

It's this change https://github.com/pnpm/npm-lifecycle/pull/41 that causes pnpm to return exit code 0 on SIGINT. released in pnpm@8.10

Ah yup, you're right. I have corepack enabled so I was using pnpm@8.9.0 from the package.json.

authors: chris-olszewski laat


text:
feat(cli): auto excludes for frameworks

We never need to cache .next/cache/**, this PR extends our framework inference to also include globs that can be automatically added to includes and excludes.
For now this is being used ONLY for the excludes on Next.js, but could be extended in the future.
NOTE: This can be done now by adding the glob to your outputs:
{
  "pipeline": {
    "build": {
      "outputs": [".next/**", "!.next/cache/**"]
    },
    "lint": {
      "outputs": []
    }
  }
}

Because we support this now, we want to solve this via documentation only instead of adding this automatically (too magic-y)

It is, but this is for outputs (what we're caching).

I'm a bit concerned that we just got rid of magic outputs defaults in #2712, and then we're adding it back in 🤔 . Would it make more sense to put this in examples/templates/docs instead of in framework inference?

Yep that's an option, that's why this PR exists (to discuss which we prefer!)

Going the docs route here

source: gharchive/pull-request

authors: mehulkar tknickman

repo: vercel/turbo

license: MIT

license_type: permissive

license_source: github-api


text:
VERGEd crashing when doing getinfo

Issue Template
Context
VERGEd crashing after doing getinfo on ubuntu  1.6
all other commands works fine, getblockhash, help, etc.
./VERGEd getinfo
============================================================ T= 1519193738
Tor 0.3.2.8-rc-dev died: Caught signal 11
./VERGEd(+0x3f74a7)[0x564da4d5d4a7]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x4)[0x7f78a3511d44]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x4)[0x7f78a3511d44]
./VERGEd(+0x78715)[0x564da49de715]
./VERGEd(+0x28b7c6)[0x564da4bf17c6]
./VERGEd(+0x2844ab)[0x564da4bea4ab]
./VERGEd(+0x2ad9f1)[0x564da4c139f1]
./VERGEd(+0x29363c)[0x564da4bf963c]
./VERGEd(+0x270dd9)[0x564da4bd6dd9]
./VERGEd(+0x98f1e)[0x564da49fef1e]
./VERGEd(+0x9cd39)[0x564da4a02d39]
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0(+0x115d5)[0x7f78a4c355d5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f78a350f6ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f78a324541d]
error: no response from server

Prerequisites

[ x] Are you running the latest version?

User Story:

"I'm submitting a ... "

[ x] bug report
[ ] feature request
[ ] support request
[ ] translation request

Your Environment

Verge Release:

[ ] I'm using Mac
[x ] I'm using Linux
[ ] I'm using Mac

can you try using boost 1.62?
(also im assuming you meant ubuntu 16, not 1.6)

source: gharchive/issue

authors: justinvforvendetta tradesatoshi

repo: vergecurrency/VERGE

license: mit

license_source: bigquery


text:
IncrementalBar has unprintable characters on Windows on Python 3.6

Python 3.6 has updated the console on Windows to print Unicode characters correctly and always use UTF-8 for sys.std[in|out|err].encoding. Unfortunately, 6 of the characters in IncrementalBar.phases do not have glyphs in the default console fonts, so the bar displays the missing glyph image (question mark in a box) while incrementing.
Programs (like pip) that check stdout.encoding is Unicode before using IncrementalBar will now use it instead of the non-incremental variety. I made the tweak below in my copy of pip and the result was acceptable, if not especially "incremental" anymore. Considering the extra glyphs are probably not going to be added anytime soon, and are unlikely to make it onto existing versions of Windows anyway, I'd like to propose this change (with appropriate comments as you wish) to avoid an ugly bar.
class IncrementalBar(Bar):
    if sys.platform.startswith('win'):
        phases = (u' ', u'▌', u'█')
    else:
        phases = (u' ', u'▏', u'▎', u'▍', u'▌', u'▋', u'▊', u'▉', u'█')

Thanks for the ping!

Thanks for the fix! :)
Do you have a timeline in mind for when you'll be releasing a version with this fix?

There's not a lot of stuff comitted since the last release but I could do a new one if nothing breaks. I'll wait at least a couple weeks to make sure nobody complains and if you are still interested then, you can ping me again to do a release.

Sure thing. No hurries. Thanks! :)

Hey @verigak!
Are you fine doing a new release now?

Released v1.4

authors: pradyunsg verigak zooba

repo: verigak/progress

license: isc


text:
Background-image support

@verlok, thank you for this plugin. I believe it can even be better if you add support for background-images both in inline CSS  and in a linked stylesheet. Thank you in advance.

Thank you. It's not what this script is meant for, but I'm open to pull requests.
If you don't feel like coding, please note that I read in other "issues" that some users were able to tweak the usage of this plugin to add support to background images without changing it.

Ok. Cool.

Also, you can use lazyload's events to determine when an image enters the viewport and use the callback to do pretty much what you want.

Understood.

On 14 May 2016, at 11:20 PM, Andrea Verlicchi notifications@github.com wrote:
Also, you can use lazyload's events to determine when an image enters the viewport and use the callback to do pretty much what you want.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/verlok/lazyload/issues/21#issuecomment-219254747

Now supported natively in version 2.0.0

authors: stalinkay verlok

repo: verlok/lazyload


text:
[Bug]: VerneMQ does not start running it with SystemD

Environment

VerneMQ Version: 1.12.6.2
OS: CentOS Stream 9
Erlang/OTP version (if building from source):
Cluster size/standalone: standalone

Current Behavior
Minimal steps to reproduce the issue:

Install vernemq 1.12.6.2 rpm directly from the official vernemq website on a brand new CentOS Stream machine
( sudo dnf install https://github.com/vernemq/vernemq/releases/download/1.12.6.2/vernemq-1.12.6.2.rocky9.x86_64.rpm )
follow the vernemq getting started guide at ( https://docs.vernemq.com/getting-started )
apply the minimal quickstart configuration mentioned here ( https://docs.vernemq.com/configuring-vernemq/introduction )
systemctl start vernemq

Current Behaviour:
Summarized behaviour
systemd vernemq service does not start or takes too long to do that.
Behaviour's details
Test #1 on a VPS with 1vCPU - 2GB RAM
The really first time vernemq was run by systemd, the following error message was shown after two minutes:
Job for vernemq.service failed because the control process exited with error code.
See "systemctl status vernemq.service" and "journalctl -xeu vernemq.service" for details.

systemctl status vernemq output is the following:
× vernemq.service - VerneMQ Server
     Loaded: loaded (/etc/systemd/system/vernemq.service; disabled; preset: disabled)
     Active: failed (Result: oom-kill) since Sat 2023-05-27 15:14:08 UTC; 3s ago
    Process: 1323 ExecStartPre=/usr/lib64/vernemq/bin/vernemq chkconfig (code=killed, signal=TERM)
        CPU: 10.811s

May 27 15:12:22 verne3 systemd[1]: Starting VerneMQ Server...
May 27 15:14:07 verne3 systemd[1]: vernemq.service: A process of this unit has been killed by the OOM killer.
May 27 15:14:07 verne3 systemd[1]: vernemq.service: Control process exited, code=killed, status=15/TERM
May 27 15:14:08 verne3 systemd[1]: vernemq.service: Failed with result 'oom-kill'.
May 27 15:14:08 verne3 systemd[1]: Failed to start VerneMQ Server.
May 27 15:14:08 verne3 systemd[1]: vernemq.service: Consumed 10.811s CPU time.

journalctl -xeu vernemq.service output is the following:
May 27 15:12:22 verne3 systemd[1]: Starting VerneMQ Server...
░░ Subject: A start job for unit vernemq.service has begun execution
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ A start job for unit vernemq.service has begun execution.
░░
░░ The job identifier is 566.
May 27 15:14:07 verne3 systemd[1]: vernemq.service: A process of this unit has been killed by the OOM killer.
░░ Subject: A process of vernemq.service unit has been killed by the OOM killer.
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ A process of unit @UNIT has been killed by the Linux kernel out-of-memory (OOM)
░░ killer logic. This usually indicates that the system is low on memory and that
░░ memory needed to be freed. A process associated with vernemq.service has been determined
░░ as the best process to terminate and has been forcibly terminated by the
░░ kernel.
░░
░░ Note that the memory pressure might or might not have been caused by vernemq.service.
May 27 15:14:07 verne3 systemd[1]: vernemq.service: Control process exited, code=killed, status=15/TERM
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ An ExecStartPre= process belonging to unit vernemq.service has exited.
░░
░░ The process' exit code is 'killed' and its exit status is 15.
May 27 15:14:08 verne3 systemd[1]: vernemq.service: Failed with result 'oom-kill'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ The unit vernemq.service has entered the 'failed' state with result 'oom-kill'.
May 27 15:14:08 verne3 systemd[1]: Failed to start VerneMQ Server.
░░ Subject: A start job for unit vernemq.service has failed
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ A start job for unit vernemq.service has finished with a failure.
░░
░░ The job identifier is 566 and the job result is failed.
May 27 15:14:08 verne3 systemd[1]: vernemq.service: Consumed 10.811s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ The unit vernemq.service completed and consumed the indicated resources.

If a service start was tried again nothing changes except the following outputs:
systemctl status vernemq becomes:
× vernemq.service - VerneMQ Server
     Loaded: loaded (/etc/systemd/system/vernemq.service; disabled; preset: disabled)
     Active: failed (Result: exit-code) since Sat 2023-05-27 15:29:49 UTC; 1min 45s ago
    Process: 1562 ExecStartPre=/usr/lib64/vernemq/bin/vernemq chkconfig (code=exited, status=1/FAILURE)
        CPU: 18.296s

May 27 15:26:33 verne3 systemd[1]: Starting VerneMQ Server...
May 27 15:29:49 verne3 vernemq[1562]: Error generating config with cuttlefish
May 27 15:29:49 verne3 vernemq[1562]:   run `vernemq config generate -l debug` for more information.
May 27 15:29:49 verne3 systemd[1]: vernemq.service: Control process exited, code=exited, status=1/FAILURE
May 27 15:29:49 verne3 systemd[1]: vernemq.service: Failed with result 'exit-code'.
May 27 15:29:49 verne3 systemd[1]: Failed to start VerneMQ Server.
May 27 15:29:49 verne3 systemd[1]: vernemq.service: Consumed 18.296s CPU time.

journalctl -xeu vernemq.service output becomes:
May 27 15:26:33 verne3 systemd[1]: Starting VerneMQ Server...
░░ Subject: A start job for unit vernemq.service has begun execution
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ A start job for unit vernemq.service has begun execution.
░░
░░ The job identifier is 628.
May 27 15:29:49 verne3 vernemq[1562]: Error generating config with cuttlefish
May 27 15:29:49 verne3 vernemq[1562]:   run `vernemq config generate -l debug` for more information.
May 27 15:29:49 verne3 systemd[1]: vernemq.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ An ExecStartPre= process belonging to unit vernemq.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
May 27 15:29:49 verne3 systemd[1]: vernemq.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ The unit vernemq.service has entered the 'failed' state with result 'exit-code'.
May 27 15:29:49 verne3 systemd[1]: Failed to start VerneMQ Server.
░░ Subject: A start job for unit vernemq.service has failed
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ A start job for unit vernemq.service has finished with a failure.
░░
░░ The job identifier is 628 and the job result is failed.
May 27 15:29:49 verne3 systemd[1]: vernemq.service: Consumed 18.296s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░
░░ The unit vernemq.service completed and consumed the indicated resources.

vernemq config generate -l debug output is the following:
2023-05-27T15:35:26.383839+00:00 [debug] Cuttlefish log level is set to debug
2023-05-27T15:35:26.399097+00:00 [debug] Parsed arguments: [{etc_dir,"/etc/vernemq"},{schema_dir,"/usr/share/vernemq/schema"},{dest_dir,"/var/lib/vernemq/generated.configs"},{conf_file,"/etc/vernemq/vernemq.conf"},{log_level,"debug"},{max_history,3},{silent,false},{allow_extra,false}]
2023-05-27T15:35:26.424384+00:00 [info] Checking /etc/vernemq/app.config exists... false
2023-05-27T15:35:26.424754+00:00 [info] Checking /etc/vernemq/vm.args exists... false
2023-05-27T15:35:26.424883+00:00 [info] No app.config or vm.args detected in /etc/vernemq, activating cuttlefish
2023-05-27T15:35:26.432261+00:00 [debug] Generating config in: "/var/lib/vernemq/generated.configs/app.2023.05.27.15.35.26.config"
2023-05-27T15:35:26.432367+00:00 [debug] Generating vm.args in: "/var/lib/vernemq/generated.configs/vm.2023.05.27.15.35.26.args"
2023-05-27T15:35:26.432789+00:00 [debug] SchemaFiles: ["/usr/share/vernemq/schema/10-vmq_server.schema","/usr/share/vernemq/schema/11-vmq_generic_msg_store.schema","/usr/share/vernemq/schema/12-vmq_plugin.schema","/usr/share/vernemq/schema/13-vmq_acl.schema","/usr/share/vernemq/schema/14-vmq_passwd.schema","/usr/share/vernemq/schema/15-vmq_diversity.schema","/usr/share/vernemq/schema/16-vmq_bcrypt.schema","/usr/share/vernemq/schema/17-vmq_webhooks.schema","/usr/share/vernemq/schema/18-vmq_bridge.schema","/usr/share/vernemq/schema/19-vmq_swc.schema","/usr/share/vernemq/schema/20-vmq_pulse.schema","/usr/share/vernemq/schema/30-vmq.schema","/usr/share/vernemq/schema/31-erlang_vm.schema","/usr/share/vernemq/schema/32-riak_sysmon.schema","/usr/share/vernemq/schema/33-eleveldb.schema"]
2023-05-27T15:35:26.604303+00:00 [debug] ConfFiles: ["/etc/vernemq/vernemq.conf"]
2023-05-27T15:35:27.095664+00:00 [debug] Adding Defaults
2023-05-27T15:35:27.098420+00:00 [debug] Right Hand Side Substitutions
2023-05-27T15:35:27.104339+00:00 [debug] Applying Datatypes
2023-05-27T15:35:27.132939+00:00 [debug] Validation
2023-05-27T15:35:27.150299+00:00 [debug] Applied 1:1 Mappings
2023-05-27T15:35:27.150709+00:00 [debug] Running translation for vmq_server.allow_multiple_sessions
2023-05-27T15:35:27.150857+00:00 [debug] Running translation for vmq_server.queue_deliver_mode
2023-05-27T15:35:27.151060+00:00 [debug] Running translation for vmq_server.queue_type
2023-05-27T15:35:27.151171+00:00 [debug] Running translation for vmq_server.reg_views
2023-05-27T15:35:27.151274+00:00 [debug] Running translation for vmq_server.persistent_client_expiration
2023-05-27T15:35:27.151366+00:00 [debug] Running translation for vmq_server.max_last_will_delay
2023-05-27T15:35:27.151475+00:00 [debug] Running translation for vmq_server.message_size_limit
2023-05-27T15:35:27.151565+00:00 [debug] Running translation for vmq_server.http_modules
2023-05-27T15:35:27.151702+00:00 [debug] Running translation for vmq_server.listeners
2023-05-27T15:35:27.237526+00:00 [debug] Running translation for vmq_server.tcp_listen_options
2023-05-27T15:35:27.237714+00:00 [debug] Running translation for vmq_server.user_plugins
2023-05-27T15:35:27.238019+00:00 [debug] Running translation for vmq_plugin.default_schema_dir
2023-05-27T15:35:27.238159+00:00 [debug] "vmq_diversity.user_scripts" in Translations to drop...
2023-05-27T15:35:27.238228+00:00 [debug] Running translation for bcrypt.pool_size
2023-05-27T15:35:27.238279+00:00 [debug] Running translation for bcrypt.nif_pool_size
2023-05-27T15:35:27.238378+00:00 [debug] Running translation for vmq_webhooks.user_webhooks
2023-05-27T15:35:27.238691+00:00 [debug] Running translation for vmq_bridge.config
2023-05-27T15:35:27.270136+00:00 [debug] Running translation for lager.handlers
2023-05-27T15:35:27.270410+00:00 [debug] Running translation for lager.crash_log
2023-05-27T15:35:27.270618+00:00 [debug] Running translation for lager.crash_log_count
2023-05-27T15:35:27.270726+00:00 [debug] "vm_args.+S" in Translations to drop...
2023-05-27T15:35:27.270849+00:00 [debug] "vm_args.+a" in Translations to drop...
2023-05-27T15:35:27.270939+00:00 [debug] "vm_args.+zdbbl" in Translations to drop...
2023-05-27T15:35:27.271206+00:00 [debug] "kernel.inet_dist_use_interface" in Translations to drop...
2023-05-27T15:35:27.271303+00:00 [debug] Running translation for riak_sysmon.gc_ms_limit
2023-05-27T15:35:27.271498+00:00 [debug] Running translation for riak_sysmon.schedule_ms_limit
2023-05-27T15:35:27.271670+00:00 [debug] Running translation for riak_sysmon.heap_word_limit
2023-05-27T15:35:27.271808+00:00 [debug] Running translation for eleveldb.delete_threshold
2023-05-27T15:35:27.271953+00:00 [debug] Running translation for eleveldb.tiered_slow_level
2023-05-27T15:35:27.272065+00:00 [debug] Applied Translations
2023-05-27T15:35:27.272143+00:00 [debug] AdvancedConfigFile: "/etc/vernemq/advanced.config"
 -config /var/lib/vernemq/generated.configs/app.2023.05.27.15.35.26.config -args_file /var/lib/vernemq/generated.configs/vm.2023.05.27.15.35.26.args -vm_args /var/lib/vernemq/generated.configs/vm.2023.05.27.15.35.26.args

Log files in /var/log/vernemq/ are empty.
Test #2 on a VPS with 1vCPU - 2GB RAM
Launching vernemq directly from command line, it starts correctly in few seconds.
Different values of leveldb.maximum_memory.percent config file option don't impact on anything.
Test #3 on a VPS with 2vCPU - 4GB RAM
After issuing the sudo systemctl start vernemq command, the service starts correctly after about 15 minutes.
Test #4 on a CentOS 8 VPS with 1vCPU -  2GB RAM
An equal VerneMQ 1.12.6.2 installation was tested also on CentOS 8 using the official binary package for Rocky Linux  8.  I did this test just to understand if this issue is "CentOS 9 dependent".
Launching the sudo systemctl start vernemq vernemq service starts in few seconds.
Expected behaviour
Expected Behaviour:
systemd vernemq service should start correctly after issuing the command  sudo systemctl start vernemq
Configuration, logs, error output, etc.
## Configuration statements different from defaults:

file vernemq.conf:

accept_eula = yes
allow_anonymous = on
leveldb.maximum_memory.percent = 70 # tested with: 70, 50, 20

Code of Conduct

[X] I agree to follow the VerneMQ's Code of Conduct

@vash83a Thanks. Strange. In the first try, you test get OOM'd by the OS, that's the simple one.
But the 15min start time just doesn't make sense. I don't think I have ever seen that. So either this is coming from Centos 9 (in combination with Verne), or maybe coming from the VPS? is the latter limiting resources or systemd start rates, or anything like that?
if you find out more, please keep us posted here.

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

FWIW: RHEL9 has the same behaviour. A strace when started with systemd on run_erl (which is consuming 100% CPU) shows a lot of
close(414105367)                        = -1 EBADF (Bad file descriptor)
close(414105368)                        = -1 EBADF (Bad file descriptor)
close(414105369)                        = -1 EBADF (Bad file descriptor)
close(414105370)                        = -1 EBADF (Bad file descriptor)
close(414105371)                        = -1 EBADF (Bad file descriptor)
close(414105372)                        = -1 EBADF (Bad file descriptor)
close(414105373)                        = -1 EBADF (Bad file descriptor)
close(414105374)                        = -1 EBADF (Bad file descriptor)
close(414105375)                        = -1 EBADF (Bad file descriptor)
close(414105376)                        = -1 EBADF (Bad file descriptor)
close(414105377)                        = -1 EBADF (Bad file descriptor)
close(414105378)                        = -1 EBADF (Bad file descriptor)
close(414105379)                        = -1 EBADF (Bad file descriptor)
close(414105380)                        = -1 EBADF (Bad file descriptor)
close(414105381)                        = -1 EBADF (Bad file descriptor)
close(414105382)                        = -1 EBADF (Bad file descriptor)
close(414105383)                        = -1 EBADF (Bad file descriptor)
close(414105384)                        = -1 EBADF (Bad file descriptor)
close(414105385)                        = -1 EBADF (Bad file descriptor)
close(414105386)                        = -1 EBADF (Bad file descriptor)
close(414105387)                        = -1 EBADF (Bad file descriptor)
I assume the systemd environment is somehow different than when you start the command line directly.

@mths1 thanks... @vash83a can you find the systemd service file for VerneMQ and show it? I don't get why the OS is trying to close file descriptors here. What is the ulimit for the VerneMQ user?

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

I guess we are running into this issue:
https://blog.rabbitmq.com/posts/2022/08/high-initial-memory-consumption-of-rabbitmq-nodes-on-centos-stream-9/
Setting the number of files to some reasonable number lets vernemq start within seconds...

One BILLION file descriptors! :1st_place_medal:

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

Thank you to you all.
@ioolkos
This is my systemd service unit configuration file:
[Unit]
Description=VerneMQ Server
After=network.target epmd@0.0.0.0.socket
Wants=network.target epmd@0.0.0.0.socket

[Service]
Type=forking
PIDFile=/run/vernemq/vernemq.pid
User=vernemq
Group=vernemq
NotifyAccess=all
LimitNOFILE=infinity
Environment="WAIT_FOR_ERLANG=3600"
TimeoutStartSec=3600
RuntimeDirectory=vernemq
WorkingDirectory=/usr/lib64/vernemq
ExecStartPre=/usr/lib64/vernemq/bin/vernemq chkconfig
ExecStart=/usr/lib64/vernemq/bin/vernemq start
ExecStop=/usr/lib64/vernemq/bin/vernemq stop
ExecStop=/bin/sh -c "while ps -p $MAINPID >/dev/null 2>&1; do sleep 1; done"

[Install]
WantedBy=multi-user.target

Hard limits for user vernemq
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 6805
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n) 524288
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) unlimited
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 6805
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

Soft limits for user vernemq
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 6805
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 6805
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

@vash83a : Please change LimitNOFILE to something reasonable, e.g. the hard limit for the user "524288" (or something smaller like 80000, as you a running on a weak VM).  In the past "infinity" didn't really mean infinity, it meant a hard limit (depending on OS, systemd). Now, the new limit on systemd is way larger than it was before, causing the memory problems and most likely also the startup problems.

@mths1
I tried to set that parameter to 80000 as you suggested and it fixed the issue. Now, the service starts in about twelve seconds. By the way, I'm still doing another test, then wait for further notice please.
From now on, it would be nice to understand which is the proper value to set, especially considering the amount of total RAM available.
I mean, what about the risk of having many GB available and having vernemq choked by that limit parameter?
thank you

The test has been completed. I adjusted the ulimit values according to the vernemq doc and warning that came out during the service start process. I confirm the issue has been fixed.
I'm still waiting for advice about LimitNOFILE values as I had mentioned earlier, if you have any.

What is needed depends on your use-case, mainly the number of clients you want to connect. I did some tests on a two node cluster and it pretty much scales linearly:
0 clients: 194
1000 clients: 1194
2000 clients: 2195
7000 clients: 7195
You might need some additional if you have database authentication, webhooks etc. enabled. Max_no_concurrent_connections * (1.5 ... 2.5) is a good rule of thumb. 1.5 should be sufficient, 2.5 gives you some margin. [This numbers are best practices we have learnt from Erlang-based brokers. I do not have numbers specificaly for VerneMQ]

repo: vernemq/vernemq


text:
[Bug] 本机UDP流量没有被clash代理

Verify Steps

[X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
[X] Latest 我已经使用最新 Dev 版本测试过，问题依旧存在
[X] Core 这是 OpenClash 存在的问题，并非我所使用的 Clash 或 Meta 等内核的特定问题
[X] Meaningful 我提交的不是无意义的 催促更新或修复 请求

OpenClash Version
v0.45.51-beta
Bug on Environment
Lean
Bug on Platform
Linux-amd64(x86-64)
To Reproduce
上游防火墙阻止1.1.1.1出站后
分别从本机(安装openclash的机器)与局域网其它机器(网关指向本机)向1.1.1.1发送udp流量
如 nslookup 1596384882.rsc.cdn77.org 1.1.1.1
结果:
本机超时
其它机器正常返回解析
已在fake ip所有类型及redir tun模式下测试 表现相同。
下述日志来自fake ip TUN模式时的情况
Describe the Bug
会有上述问题的原因是发现我这边fallback filter工作不正常
1596384882.rsc.cdn77.org 这个域名应该走fallback dns解析到香港区域
局域网机器上nslookup可以获得香港区域的ip(因为udp能走代理)
但是openclash机器获得的是美国区域，这与本地直连不经过代理获得的结果一致
所以开始排查dns解析过程，发现了上面的udp代理的问题
...测试方法如下
1、在上游网关的防火墙阻止1.1.1.1出站流量
curl 1.1.1.1在本机和局域网其它机器测试tcp通
说明1.1.1.1的tcp流量走了openclash的代理
2、不阻止1.1.1.1出站
nslookup 1596384882.rsc.cdn77.org 1.1.1.1
测试根据udp结果判断是否有走代理
走代理的时候会返回香港ip，不走的时候会返回美国ip
结果是安装openclash的机器返回美国IP
局域网的其它机器返回香港IP
同时上游的防火墙在openclash的机器发出请求时能识别到1.1.1.1 53端口出站流量
在局域网其它机器发出请求时没有53端口出站流量
如果阻止1.1.1.1出站则局域网机器有返回，本机超时
结论是似乎只有安装openclash的本机udp有问题，以openclash做网关的其它机器tcp udp都能被正常代理到
排除了openclash机器防火墙的原因：
fake ip TUN模式
tcp udp都是通过下面两条规则发送到clash
-A PREROUTING -j openclash
-A OUTPUT -j openclash_output
同时检查了没有针对udp 53端口的其他规则
OpenClash Log
OpenClash 调试日志
生成时间: 2022-08-31 05:00:00
插件版本: v0.45.51-beta
隐私提示: 上传此日志前请注意检查、屏蔽公网IP、节点、密码等相关敏感信息

#===================== 系统信息 =====================#

主机型号: QEMU Standard PC (i440FX + PIIX - Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz : 16 Core 16 Thread
固件版本: OpenWrt SNAPSHOT r4849-c2f62b177
LuCI版本: git-22.225.38104-d169a90-1
内核版本: 5.15.60
处理器架构: x86_64

#此项有值时,如不使用IPv6,建议到网络-接口-lan的设置中禁用IPV6的DHCP
IPV6-DHCP:

#此项结果应仅有配置文件的DNS监听地址
Dnsmasq转发设置: 127.0.0.1#5303

#===================== 依赖检查 =====================#

dnsmasq-full: 已安装
coreutils: 已安装
coreutils-nohup: 已安装
bash: 已安装
curl: 已安装
ca-certificates: 已安装
ipset: 已安装
ip-full: 已安装
iptables-mod-tproxy: 已安装
kmod-ipt-tproxy: 已安装
iptables-mod-extra: 已安装
kmod-ipt-extra: 已安装
libcap: 已安装
libcap-bin: 已安装
ruby: 已安装
ruby-yaml: 已安装
ruby-psych: 已安装
ruby-pstore: 已安装
kmod-tun(TUN模式): 已安装
luci-compat(Luci-19.07): 已安装
kmod-inet-diag(PROCESS-NAME): 已安装
unzip: 已安装

#===================== 内核检查 =====================#

运行状态: 运行中
进程pid: 4120
运行权限: 4120: cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_ptrace,cap_sys_resource=eip
运行用户: nobody
已选择的架构: linux-amd64

#下方无法显示内核版本号时请确认您的内核版本是否正确或者有无权限
Tun内核版本: 2022.07.07-14-g6950e48
Tun内核文件: 存在
Tun内核运行权限: 正常

Dev内核版本: v1.11.4-13-g6e058f8
Dev内核文件: 存在
Dev内核运行权限: 正常

Meta内核版本:
Meta内核文件: 不存在
Meta内核运行权限: 否

#===================== 插件设置 =====================#

当前配置文件: /etc/openclash/config/amy.yaml
启动配置文件: /etc/openclash/amy.yaml
运行模式: fake-ip-tun
默认代理模式: rule
UDP流量转发(tproxy): 停用
DNS劫持: 停用
自定义DNS: 启用
IPV6代理: 停用
IPV6-DNS解析: 停用
禁用Dnsmasq缓存: 启用
自定义规则: 停用
仅允许内网: 启用
仅代理命中规则流量: 停用
仅允许常用端口流量: 停用
绕过中国大陆IP: 停用
DNS远程解析: 启用
路由本机代理: 启用

#启动异常时建议关闭此项后重试
混合节点: 停用
保留配置: 停用

#启动异常时建议关闭此项后重试
第三方规则: 停用

#===================== 配置文件 =====================#

port: 7890
socks-port: 7891
allow-lan: true
mode: rule
log-level: silent
external-controller: 0.0.0.0:9090
proxy-groups:
- name: Proxies
  type: select
  proxies:
  - HK
  - SG
  - JP
  - US
  - TW
- name: Netflix
  type: select
  proxies:
  - Proxies
  - HK
  - SG
  - JP
  - US
  - TW
- name: 海外流媒体
  type: select
  proxies:
  - Proxies
  - HK
  - SG
  - JP
  - US
  - TW
- name: 海外IM
  type: select
  proxies:
  - Proxies
  - HK
  - SG
  - JP
  - US
  - TW
- name: 港澳IP
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - HK
  - Proxies
- name: 台湾IP
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - TW
  - Proxies
- name: 日韩IP
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - JP
  - Proxies
- name: 大洋洲IP
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - SG
  - Proxies
- name: 美洲IP
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - US
  - Proxies
- name: NO-MATCH
  type: select
  proxies:
  - DIRECT
  - Proxies
- name: HK
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - "香港"
- name: SG
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - "新加坡"
- name: TW
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - "台湾"
- name: JP
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - "日本"
- name: US
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 600
  proxies:
  - "美国"
rules:
- DST-PORT,7895,REJECT
- DST-PORT,7892,REJECT
- DST-PORT,123,DIRECT
- IP-CIDR,1.1.1.1/32,Proxies,no-resolve
- GEOIP,CN,DIRECT
- GEOIP,US,美洲IP
- GEOIP,CA,美洲IP
- GEOIP,HK,港澳IP
- GEOIP,MO,港澳IP
- GEOIP,TW,台湾IP
- GEOIP,SG,大洋洲IP
- GEOIP,AU,大洋洲IP
- GEOIP,JP,日韩IP
- GEOIP,KR,日韩IP
- MATCH,NO-MATCH
redir-port: 7892
tproxy-port: 7895
mixed-port: 7893
bind-address: "*"
external-ui: "/usr/share/openclash/ui"
ipv6: false
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  listen: 0.0.0.0:7874
  nameserver:
  - 114.114.114.114
  - 119.29.29.29
  - 223.5.5.5
  - https://doh.pub/dns-query
  - https://dns.alidns.com/dns-query
  fallback:
  - https://dns.cloudflare.com/dns-query
  - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
    - 0.0.0.0/8
    - 10.0.0.0/8
    - 100.64.0.0/10
    - 127.0.0.0/8
    - 169.254.0.0/16
    - 172.16.0.0/12
    - 192.0.0.0/24
    - 192.0.2.0/24
    - 192.88.99.0/24
    - 192.168.0.0/16
    - 198.18.0.0/15
    - 198.51.100.0/24
    - 203.0.113.0/24
    - 224.0.0.0/4
    - 240.0.0.0/4
    - 255.255.255.255/32
    domain:
    - "+.google.com"
    - "+.facebook.com"
    - "+.youtube.com"
    - "+.githubusercontent.com"
    - "+.googlevideo.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"
    - msftconnecttest.com
    - msftncsi.com
  fake-ip-filter:
  - "*.lan"
  - "*.localdomain"
  - "*.example"
  - "*.invalid"
  - "*.localhost"
  - "*.test"
  - "*.local"
  - "*.home.arpa"
  - time.*.com
  - time.*.gov
  - time.*.edu.cn
  - time.*.apple.com
  - time-ios.apple.com
  - time1.*.com
  - time2.*.com
  - time3.*.com
  - time4.*.com
  - time5.*.com
  - time6.*.com
  - time7.*.com
  - ntp.*.com
  - ntp1.*.com
  - ntp2.*.com
  - ntp3.*.com
  - ntp4.*.com
  - ntp5.*.com
  - ntp6.*.com
  - ntp7.*.com
  - "*.time.edu.cn"
  - "*.ntp.org.cn"
  - "+.pool.ntp.org"
  - time1.cloud.tencent.com
  - music.163.com
  - "*.music.163.com"
  - "*.126.net"
  - musicapi.taihe.com
  - music.taihe.com
  - songsearch.kugou.com
  - trackercdn.kugou.com
  - "*.kuwo.cn"
  - api-jooxtt.sanook.com
  - api.joox.com
  - joox.com
  - y.qq.com
  - "*.y.qq.com"
  - streamoc.music.tc.qq.com
  - mobileoc.music.tc.qq.com
  - isure.stream.qqmusic.qq.com
  - dl.stream.qqmusic.qq.com
  - aqqmusic.tc.qq.com
  - amobile.music.tc.qq.com
  - "*.xiami.com"
  - "*.music.migu.cn"
  - music.migu.cn
  - "+.msftconnecttest.com"
  - "+.msftncsi.com"
  - msftconnecttest.com
  - msftncsi.com
  - localhost.ptlogin2.qq.com
  - localhost.sec.qq.com
  - "+.srv.nintendo.net"
  - "*.n.n.srv.nintendo.net"
  - "+.stun.playstation.net"
  - xbox.*.*.microsoft.com
  - "*.*.xboxlive.com"
  - xbox.*.microsoft.com
  - xnotify.xboxlive.com
  - "+.battlenet.com.cn"
  - "+.wotgame.cn"
  - "+.wggames.cn"
  - "+.wowsgame.cn"
  - "+.wargaming.net"
  - proxy.golang.org
  - stun.*.*
  - stun.*.*.*
  - "+.stun.*.*"
  - "+.stun.*.*.*"
  - "+.stun.*.*.*.*"
  - "+.stun.*.*.*.*.*"
  - heartbeat.belkin.com
  - "*.linksys.com"
  - "*.linksyssmartwifi.com"
  - "*.router.asus.com"
  - mesu.apple.com
  - swscan.apple.com
  - swquery.apple.com
  - swdownload.apple.com
  - swcdn.apple.com
  - swdist.apple.com
  - lens.l.google.com
  - stun.l.google.com
  - "+.nflxvideo.net"
  - "*.square-enix.com"
  - "*.finalfantasyxiv.com"
  - "*.ffxiv.com"
  - "*.ff14.sdo.com"
  - ff.dorado.sdo.com
  - "*.mcdn.bilivideo.cn"
  - "+.media.dssott.com"
  - shark007.net
  - Mijia Cloud
  - "+.dns.google"
experimental:
  sniff-tls-sni: true
tun:
  enable: true
  stack: system
  auto-route: false
  auto-detect-interface: false
  dns-hijack:
  - tcp://any:53
profile:
  store-selected: true
  store-fake-ip: true

#===================== 防火墙设置 =====================#

#IPv4 NAT chain

# Generated by iptables-save v1.8.7 on Wed Aug 31 05:00:02 2022
*nat
:PREROUTING ACCEPT [14748:2605393]
:INPUT ACCEPT [7109:1421112]
:OUTPUT ACCEPT [7141:467522]
:POSTROUTING ACCEPT [7035:469757]
:MINIUPNPD - [0:0]
:MINIUPNPD-POSTROUTING - [0:0]
:postrouting_VPN_rule - [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_VPN_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_VPN_postrouting - [0:0]
:zone_VPN_prerouting - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
-A PREROUTING -p tcp -m comment --comment "OpenClash TCP DNS Hijack" -m tcp --dport 53 -j ACCEPT
-A PREROUTING -m comment --comment "!fw3: Custom prerouting rule chain" -j prerouting_rule
-A PREROUTING -i br-lan -m comment --comment "!fw3" -j zone_lan_prerouting
-A POSTROUTING -m comment --comment "!fw3: Custom postrouting rule chain" -j postrouting_rule
-A POSTROUTING -o br-lan -m comment --comment "!fw3" -j zone_lan_postrouting
-A zone_VPN_postrouting -m comment --comment "!fw3: Custom VPN postrouting rule chain" -j postrouting_VPN_rule
-A zone_VPN_prerouting -m comment --comment "!fw3: Custom VPN prerouting rule chain" -j prerouting_VPN_rule
-A zone_lan_postrouting -j MINIUPNPD-POSTROUTING
-A zone_lan_postrouting -m comment --comment "!fw3: Custom lan postrouting rule chain" -j postrouting_lan_rule
-A zone_lan_postrouting -m comment --comment "!fw3" -j FULLCONENAT
-A zone_lan_prerouting -j MINIUPNPD
-A zone_lan_prerouting -m comment --comment "!fw3: Custom lan prerouting rule chain" -j prerouting_lan_rule
-A zone_lan_prerouting -m comment --comment "!fw3" -j FULLCONENAT
-A zone_wan_postrouting -m comment --comment "!fw3: Custom wan postrouting rule chain" -j postrouting_wan_rule
-A zone_wan_postrouting -m comment --comment "!fw3" -j FULLCONENAT
-A zone_wan_prerouting -m comment --comment "!fw3: Custom wan prerouting rule chain" -j prerouting_wan_rule
-A zone_wan_prerouting -m comment --comment "!fw3" -j FULLCONENAT
COMMIT
# Completed on Wed Aug 31 05:00:02 2022

#IPv4 Mangle chain

# Generated by iptables-save v1.8.7 on Wed Aug 31 05:00:02 2022
*mangle
:PREROUTING ACCEPT [168677:33715011]
:INPUT ACCEPT [141532:31282148]
:FORWARD ACCEPT [23051:1485820]
:OUTPUT ACCEPT [143601:30568586]
:POSTROUTING ACCEPT [158726:31738965]
:openclash - [0:0]
:openclash_dns_hijack - [0:0]
:openclash_output - [0:0]
-A PREROUTING -j openclash
-A FORWARD -o br-lan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone lan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i br-lan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone lan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
-A OUTPUT -j openclash_output
-A openclash -p tcp -m tcp --sport 1688 -j RETURN
-A openclash -p udp -m udp --sport 4500 -j RETURN
-A openclash -p udp -m udp --sport 500 -j RETURN
-A openclash -p udp -m udp --sport 500 -j RETURN
-A openclash -p udp -m udp --sport 68 -j RETURN
-A openclash -m set --match-set localnetwork dst -j RETURN
-A openclash -j MARK --set-xmark 0x162/0xffffffff
-A openclash_output -p tcp -m tcp --sport 1688 -j RETURN
-A openclash_output -p udp -m udp --sport 4500 -j RETURN
-A openclash_output -p udp -m udp --sport 500 -j RETURN
-A openclash_output -p udp -m udp --sport 500 -j RETURN
-A openclash_output -p udp -m udp --sport 68 -j RETURN
-A openclash_output -m set --match-set localnetwork dst -j RETURN
-A openclash_output -d 198.18.0.0/16 -m owner ! --uid-owner 65534 -j MARK --set-xmark 0x162/0xffffffff
-A openclash_output -p tcp -m owner ! --uid-owner 65534 -j MARK --set-xmark 0x162/0xffffffff
COMMIT
# Completed on Wed Aug 31 05:00:02 2022

#IPv4 Filter chain

# Generated by iptables-save v1.8.7 on Wed Aug 31 05:00:02 2022
*filter
:INPUT ACCEPT [14590:906185]
:FORWARD ACCEPT [109:17094]
:OUTPUT ACCEPT [116:18184]
:MINIUPNPD - [0:0]
:forwarding_VPN_rule - [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_VPN_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_VPN_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:zone_VPN_dest_ACCEPT - [0:0]
:zone_VPN_forward - [0:0]
:zone_VPN_input - [0:0]
:zone_VPN_output - [0:0]
:zone_VPN_src_ACCEPT - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
-A INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A FORWARD -o utun -p udp -m udp --dport 443 -m comment --comment "OpenClash QUIC REJECT" -m set ! --match-set china_ip_route dst -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o utun -m comment --comment "OpenClash TUN Forward" -j ACCEPT
-A FORWARD -m policy --dir out --pol ipsec --proto esp -j ACCEPT
-A FORWARD -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
-A zone_VPN_forward -m comment --comment "!fw3: Custom VPN forwarding rule chain" -j forwarding_VPN_rule
-A zone_VPN_forward -m comment --comment "!fw3: Zone VPN to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_VPN_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_VPN_forward -m comment --comment "!fw3" -j zone_VPN_dest_ACCEPT
-A zone_VPN_input -m comment --comment "!fw3: Custom VPN input rule chain" -j input_VPN_rule
-A zone_VPN_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_VPN_input -m comment --comment "!fw3" -j zone_VPN_src_ACCEPT
-A zone_VPN_output -m comment --comment "!fw3: Custom VPN output rule chain" -j output_VPN_rule
-A zone_VPN_output -m comment --comment "!fw3" -j zone_VPN_dest_ACCEPT
-A zone_lan_dest_ACCEPT -o br-lan -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -j MINIUPNPD
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
-A zone_wan_input -p tcp -m tcp --dport 8118 -m comment --comment "!fw3: adblock" -j DROP
-A zone_wan_input -p udp -m udp --dport 500 -m comment --comment "!fw3: ike" -j ACCEPT
-A zone_wan_input -p udp -m udp --dport 4500 -m comment --comment "!fw3: ipsec" -j ACCEPT
-A zone_wan_input -p ah -m comment --comment "!fw3: ah" -j ACCEPT
-A zone_wan_input -p esp -m comment --comment "!fw3: esp" -j ACCEPT
-A zone_wan_input -p tcp -m tcp --dport 1688 -m comment --comment "!fw3: kms" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
COMMIT
# Completed on Wed Aug 31 05:00:02 2022

#IPv6 NAT chain

# Generated by ip6tables-save v1.8.7 on Wed Aug 31 05:00:02 2022
*nat
:PREROUTING ACCEPT [3934:1015980]
:INPUT ACCEPT [16:1232]
:OUTPUT ACCEPT [15:2372]
:POSTROUTING ACCEPT [15:2372]
COMMIT
# Completed on Wed Aug 31 05:00:02 2022

#IPv6 Mangle chain

# Generated by ip6tables-save v1.8.7 on Wed Aug 31 05:00:02 2022
*mangle
:PREROUTING ACCEPT [4550:1063085]
:INPUT ACCEPT [84:5968]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23:3601]
:POSTROUTING ACCEPT [23:3601]
-A FORWARD -o br-lan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone lan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i br-lan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone lan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Wed Aug 31 05:00:02 2022

#IPv6 Filter chain

# Generated by ip6tables-save v1.8.7 on Wed Aug 31 05:00:02 2022
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:MINIUPNPD - [0:0]
:forwarding_VPN_rule - [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_VPN_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_VPN_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:zone_VPN_dest_ACCEPT - [0:0]
:zone_VPN_forward - [0:0]
:zone_VPN_input - [0:0]
:zone_VPN_output - [0:0]
:zone_VPN_src_ACCEPT - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp6-port-unreachable
-A zone_VPN_forward -m comment --comment "!fw3: Custom VPN forwarding rule chain" -j forwarding_VPN_rule
-A zone_VPN_forward -m comment --comment "!fw3: Zone VPN to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_VPN_forward -m comment --comment "!fw3" -j zone_VPN_dest_ACCEPT
-A zone_VPN_input -m comment --comment "!fw3: Custom VPN input rule chain" -j input_VPN_rule
-A zone_VPN_input -m comment --comment "!fw3" -j zone_VPN_src_ACCEPT
-A zone_VPN_output -m comment --comment "!fw3: Custom VPN output rule chain" -j output_VPN_rule
-A zone_VPN_output -m comment --comment "!fw3" -j zone_VPN_dest_ACCEPT
-A zone_lan_dest_ACCEPT -o br-lan -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -j MINIUPNPD
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 129 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 1 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 2 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 3 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 4/0 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Forward" -j ACCEPT
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule
-A zone_wan_input -s fc00::/6 -d fc00::/6 -p udp -m udp --dport 546 -m comment --comment "!fw3: Allow-DHCPv6" -j ACCEPT
-A zone_wan_input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130/0 -m comment --comment "!fw3: Allow-MLD" -j ACCEPT
-A zone_wan_input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131/0 -m comment --comment "!fw3: Allow-MLD" -j ACCEPT
-A zone_wan_input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132/0 -m comment --comment "!fw3: Allow-MLD" -j ACCEPT
-A zone_wan_input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143/0 -m comment --comment "!fw3: Allow-MLD" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 129 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 1 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 2 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 3 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 4/0 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m limit --limit 1000/sec -m comment --comment "!fw3: Allow-ICMPv6-Input" -j ACCEPT
-A zone_wan_input -p tcp -m tcp --dport 8118 -m comment --comment "!fw3: adblock" -j DROP
-A zone_wan_input -p udp -m udp --dport 500 -m comment --comment "!fw3: ike" -j ACCEPT
-A zone_wan_input -p udp -m udp --dport 4500 -m comment --comment "!fw3: ipsec" -j ACCEPT
-A zone_wan_input -p ah -m comment --comment "!fw3: ah" -j ACCEPT
-A zone_wan_input -p esp -m comment --comment "!fw3: esp" -j ACCEPT
-A zone_wan_input -p tcp -m tcp --dport 1688 -m comment --comment "!fw3: kms" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
COMMIT
# Completed on Wed Aug 31 05:00:02 2022

#===================== IPSET状态 =====================#

Name: china_ip_route
Name: china_ip_route_pass
Name: localnetwork
Name: music

#===================== 路由表状态 =====================#

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 br-lan
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 br-lan
198.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 utun
#ip route list
default via 192.168.10.1 dev br-lan proto static
192.168.10.0/24 dev br-lan proto kernel scope link src 192.168.10.2
198.18.0.0/16 dev utun proto kernel scope link src 198.18.0.1
#ip rule show
0:	from all lookup local
32765:	from all fwmark 0x162 lookup 354
32766:	from all lookup main
32767:	from all lookup default

#===================== Tun设备状态 =====================#

utun: tun

#===================== 端口占用状态 =====================#

tcp        0      0 198.18.0.1:7777         0.0.0.0:*               LISTEN      4120/clash
tcp        0      0 :::7890                 :::*                    LISTEN      4120/clash
tcp        0      0 :::7891                 :::*                    LISTEN      4120/clash
tcp        0      0 :::7895                 :::*                    LISTEN      4120/clash
tcp        0      0 :::7892                 :::*                    LISTEN      4120/clash
tcp        0      0 :::7893                 :::*                    LISTEN      4120/clash
tcp        0      0 :::9090                 :::*                    LISTEN      4120/clash
udp        0      0 198.18.0.1:7777         0.0.0.0:*                           4120/clash
udp        0      0 :::40363                :::*                                4120/clash
udp        0      0 :::7874                 :::*                                4120/clash
udp        0      0 :::7891                 :::*                                4120/clash
udp        0      0 :::7892                 :::*                                4120/clash
udp        0      0 :::7893                 :::*                                4120/clash
udp        0      0 :::7895                 :::*                                4120/clash
udp        0      0 :::48990                :::*                                4120/clash
udp        0      0 :::38817                :::*                                4120/clash
udp        0      0 :::53238                :::*                                4120/clash
udp        0      0 :::47225                :::*                                4120/clash
udp        0      0 :::45346                :::*                                4120/clash
udp        0      0 :::51943                :::*                                4120/clash
udp        0      0 :::60451                :::*                                4120/clash

#===================== 测试本机DNS查询 =====================#

Server:		127.0.0.1
Address:	127.0.0.1:53

Non-authoritative answer:

Name:	www.baidu.com
Address: 198.18.0.4

#===================== resolv.conf.d =====================#

# Interface lan
nameserver 119.29.29.29

#===================== 测试本机网络连接 =====================#

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Length: 277
Content-Type: text/html
Date: Tue, 30 Aug 2022 21:00:03 GMT
Etag: "575e1f71-115"
Last-Modified: Mon, 13 Jun 2016 02:50:25 GMT
Pragma: no-cache
Server: bfe/1.0.8.18

#===================== 测试本机网络下载 =====================#

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 80
Cache-Control: max-age=300
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
Content-Type: text/plain; charset=utf-8
ETag: "7b18c764d6c4574c6040f0dc7b80bc6a8df5289c8cdd0b3dd1df70ea589c5314"
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
X-GitHub-Request-Id: DF9C:62C0:6CB64:C5ACA:630D32ED
Accept-Ranges: bytes
Date: Tue, 30 Aug 2022 21:00:03 GMT
Via: 1.1 varnish
X-Served-By: cache-hkg17927-HKG
X-Cache: HIT
X-Cache-Hits: 2
X-Timer: S1661893203.321111,VS0,VE0
Vary: Authorization,Accept-Encoding,Origin
Access-Control-Allow-Origin: *
X-Fastly-Request-ID: 4fdc474ede6b78ffd0a483b2116415dcf3e6795c
Expires: Tue, 30 Aug 2022 21:05:03 GMT
Source-Age: 279

#===================== 最近运行日志 =====================#

2022-08-31 04:17:43 OpenClash Stoping...
2022-08-31 04:17:43 Step 1: Backup The Current Groups State...
2022-08-31 04:17:43 Step 2: Delete OpenClash Firewall Rules...
2022-08-31 04:17:44 Step 3: Close The OpenClash Daemons...
2022-08-31 04:17:44 Step 4: Close The Clash Core Process...
2022-08-31 04:17:44 Step 5: Restart Dnsmasq...
2022-08-31 04:17:44 Step 6: Delete OpenClash Residue File...
2022-08-31 04:17:44 OpenClash Start Running...
2022-08-31 04:17:44 Step 1: Get The Configuration...
2022-08-31 04:17:44 Step 2: Check The Components...
2022-08-31 04:17:45 Step 3: Modify The Config File...
2022-08-31 04:17:46 Setting Secondary DNS Server List...
2022-08-31 04:17:46 Step 4: Start Running The Clash Core...
2022-08-31 04:17:46 Tip: Detected The Exclusive Function of The TUN Core, Use TUN Core to Start...
2022-08-31 04:17:47 Step 5: Check The Core Status...
。。。
time="2022-08-30T20:17:47Z" level=info msg="DNS server listening at: [::]:7874"
2022-08-31 04:17:50 Step 6: Wait For The File Downloading...
2022-08-31 04:17:50 Step 7: Set Firewall Rules...
2022-08-31 04:17:50 Step 8: Restart Dnsmasq...
2022-08-31 04:17:50 Step 9: Add Cron Rules, Start Daemons...
2022-08-31 04:17:50 OpenClash Start Successful!
2022-08-31 04:17:52 Reload OpenClash Firewall Rules...

OpenClash Config
No response
Expected Behavior
对匹配代理规则的从本机发出的udp流量能够通过代理连接
Screenshots
No response

你没有看更新公告？默认本机不代理自身的udp

默认不代理，容易出问题

默认不代理，容易出问题

谢谢回复，
可是这样的话fallback的海外dns不走代理，
有些基于地理位置的DNS记录会返回较远的地区（比如CDN77，国内IP会被返回美国区域）
这个对GEOIP的规则会有点影响。
请问一下能否考虑由openClash发出的流量继续走代理规则判断呢？

用meta

用meta

谢谢🙏
已经解决，openclash自己的dns流量用了meta内核可以进代理链了

repo: vernesong/OpenClash


text:
[Bug] oracle 增量同步一段时间后内部从LogMiner中获取更改的循环报NULL指针异常

Search before asking

[X] I searched in the issues and found nothing similar.

Flink version
flink 1.16.2
Flink CDC version
cdc 2.4
Database and its version
oracle 19
Minimal reproduce step
提交代码
EXECUTE CDCSOURCE SUCCEZ_TEST.sqlplus-BZDIP.testOracle_1 WITH (
'connector' = 'oracle-cdc',
'hostname' = '192.168.10.205',
'port' = '1521',
'username' = 'succez_test',
'password' = 'xxxxxx',
'database-name' = 'orcl',
'parallelism' = '2',
'checkpoint' = '30',
'scan.startup.mode' = 'initial',
'table-name' = 'SUCCEZ_TEST.TEST_TABLE',
'debezium.database.history.store.only.captured.tables.ddl' = 'true',
'debezium.database.tablename.case.insensitive' = 'false',
'debezium.log.mining.strategy' = 'online_catalog',
'debezium.decimal.handling.mode' = 'string',
'debezium.connector.buffer.size' = '2048',
'sink.table.prefix' = 'ODS_',
'sink.table-name' ='BZDIP.${tableName}',
'sink.connector' = 'jdbc',
'sink.url' = 'jdbc:oracle:thin:@//192.168.10.25:1521/ws',
'sink.username' = 'bzdip',
'sink.password' = 'xxxxxx')
What did you expect to see?
能过解决此问题
What did you see instead?
oracle增量同步，运行一段时间后，就报了此错误
2023-11-17 15:10:17,763 INFO  org.apache.flink.runtime.executiongraph.ExecutionGraph       [] - Source: Oracle CDC Source -> Map -> Process -> (Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map, Flat Map) (1/1) (d18d12b9f1b7edb7aa81ca0c6b1ef526_cbc357ccb763df2852fee8c4fc7d55f2_0_3) switched from RUNNING to FAILED on localhost:10657-22f939 @ localhost (dataPort=11178).
com.ververica.cdc.connectors.shaded.org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped.
at io.debezium.pipeline.ErrorHandler.setProducerThrowable(ErrorHandler.java:50) ~[flink-sql-connector-mysql-cdc-2.4-
SNAPSHOT.jar:2.4-SNAPSHOT]
at io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource.execute(LogMinerStreamingChangeEventSource.java:261) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT]
at io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource.execute(LogMinerStreamingChangeEventSource.java:70) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT]
at io.debezium.pipeline.ChangeEventSourceCoordinator.streamEvents(ChangeEventSourceCoordinator.java:174) ~[flink-sql-connector-mysql-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT]
at io.debezium.pipeline.ChangeEventSourceCoordinator.executeChangeEventSources(ChangeEventSourceCoordinator.java:141) ~[flink-sql-connector-mysql-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT]
at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:109) ~[flink-sql-connector-mysql-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: java.lang.NullPointerException
Anything else?
No response
Are you willing to submit a PR?

[X] I'm willing to submit a PR!

原本异常内部被优化了，需要增加JVM启动参数后才能将实际的异常输出，看着是row为空导致的null异常。
java.lang.NullPointerException: null 	at io.debezium.connector.oracle.logminer.processor.AbstractLogMinerEventProcessor.processRow(AbstractLogMinerEventProcessor.java:278) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.connector.oracle.logminer.processor.AbstractLogMinerEventProcessor.processResults(AbstractLogMinerEventProcessor.java:262) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.connector.oracle.logminer.processor.AbstractLogMinerEventProcessor.process(AbstractLogMinerEventProcessor.java:198) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource.execute(LogMinerStreamingChangeEventSource.java:247) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource.execute(LogMinerStreamingChangeEventSource.java:70) ~[flink-sql-connector-oracle-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.pipeline.ChangeEventSourceCoordinator.streamEvents(ChangeEventSourceCoordinator.java:174) ~[flink-sql-connector-mysql-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.pipeline.ChangeEventSourceCoordinator.executeChangeEventSources(ChangeEventSourceCoordinator.java:141) ~[flink-sql-connector-mysql-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:109) ~[flink-sql-connector-mysql-cdc-2.4-SNAPSHOT.jar:2.4-SNAPSHOT] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] 	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] 	at java.lang.Thread.run(Thread.java:834) [?:?]

Considering collaboration with developers around the world, please re-create your issue in English on Apache Jira under project Flink with component tag 'Flink CDC'. Thanks.
为了便于各个国家的开发者合作，请用英文在 Apache Jira 的 Flink项目下重新提交问题，同时将 issue 的 Component 标注为 Flink CDC。谢谢。

repo: ververica/flink-cdc-connectors


text:
[cdc-pipeline-connector][starrocks] Introduce starrocks cdc pipeline DataSink

This close #2645. Add Implementation of DataSink for StarRocks which supports

StarRocks primary key table + at-least-once for idempotent writing
schema changes including CreateTableEvent, AddColumnEvent and DropColumnEvent. Other types of schema change will be supported in the following pr.

Resolved by 33b7c85093a69382d23c309a9b209ddae27a2968

authors: banmoy leonardBang


text:
Adapte to VVP API change

Use deployment target name instead of id
Set deployment name to jupyter+random

This change is required for jupytervvp to work with the latest VVP due to the VVP REST API changes: using name instead of id

repo: ververica/jupyter-vvp


text:
🛑 ipfs.cat is down

In ee9745c, ipfs.cat (https://ipfs.cat) was down:

HTTP code: 520
Response time: 281 ms

Resolved: ipfs.cat is back up in cb18642 after 7 minutes.

repo: vesahc/upptime-pln


text:
Meta handles leader changes and other errorcodes uniformly

For meta, when the leader changes, it is not handled correctly in most cases, and an incorrect error code is returned. So the leader of the meta was changed, but the meta client received other error codes and did not try again.
This pr uniformly handles the error codes of various operations in meta BaseProcessor and so on.
benefit:

The leader change situation of meta can be processed uniformly .
It also facilitates the unified processing of subsequent errorcodes.

Depend on https://github.com/vesoft-inc/nebula-common/pull/494

Good, just remove all StatusOr in meta...

nice job，massive project.

Conflict again, maybe because there are several reverts these days. You could contact @liuyu85cn if necessary.

test passed, ready to review.

repo: vesoft-inc/nebula-storage


text:
Implement Struct

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Needs CI to be ran again as it got confused and ended up not running

repo: vespa-engine/pyvespa


text:
Tiny adjustment to SetScrollMargin

I noticed that the minimum size supported by a scroll region is 2 lines. Docs for DECSTBM say top must be less than bottom, not less-or-equal.
So this little check could use adjusting:
https://github.com/vezel-dev/cathode/blob/6bd76d8836c1988d96c58283de037de63f5e8ab9/src/core/Text/Control/ControlBuilder.cs#L404

Hmm, maybe have an exception for 1-line-high terminals. This can happen when shrinking a tmux pane to be a single line - I do this sometimes to show just the status part of a cli app. In that case, top == bottom == 0 would be reasonable to allow.

It's been a hot minute since I wrote that code. I do remember that I wrote those argument checks to explicitly deviate from the DECSTBM docs based on some practical observations in various terminal emulators. I don't remember the details though...

Hmm, here's a comment in a past version of the code that might provide a clue: https://github.com/vezel-dev/cathode/commit/fd39193da1bd33f765dcca6f54a48eba6f090fac#diff-e6adf24d6af11f0dd8712eef8db7057bce1e9cd5638a34c85c6bf57f40c83de1L154-L159

https://github.com/vezel-dev/cathode/commit/1be04581cf96b4e0a401af195bd1f9a5b653fdf4#diff-f073a637a71441a937949ae38f90bc731d869f043ebc4a1e6ee62d447e4a2329L400-R402

Hmm, here's a comment in a past version of the code that might provide a clue: fd39193#diff-e6adf24d6af11f0dd8712eef8db7057bce1e9cd5638a34c85c6bf57f40c83de1L154-L159

Which was removed in fd39193da1bd33f765dcca6f54a48eba6f090fac.

I think the odd behavior I observed was with Windows Terminal. Any chance I could get you to test loosening those checks and see how Windows Terminal behaves with such values? (Especially if you resize the terminal window to be as small as possible.)

In Windows Terminal (I am on 1.20.11381.0) it behaves according to docs and the same as tmux: bottom <= top is an error case, any DECSTBM with error params is ignored, and will not change whatever the margins were previously.

However, I do believe I've found some odd behavior in Windows Terminal when the window is resized...
If I do not set scroll margins, then resizing the window will always keep the margins to the full window. But if I manually set the margins to 0,height-1, then - sometimes - when I make the window taller, it will not keep the bottom margin stuck to the bottom of the window. Doing a DECSTBM with no coords (i.e. apply defaults) restores the correct behavior.
I haven't tried to pin this issue down specifically, instead added a ResetScrollMargins() => _cb.Print(CSI).Print(";r").
Note that tmux behaves correctly - the bottom scroll margin in a resizing pane is always sticky when set to height-1.

Thinking about it a bit more, I think I'm just inclined to follow the DECSTBM documentation on this. So I'll loosen that check.
Also, good call on needing a ResetScrollMargins() method!

@scottbilas just to clarify regarding https://github.com/vezel-dev/cathode/issues/180#issuecomment-2183426066, is there actually a case where top == bottom == 0 has an effect? My understanding is that this is technically an error and will go ignored. See e.g. https://github.com/microsoft/terminal/issues/1849.

authors: alexrp scottbilas

repo: vezel-dev/cathode


text:
AttributeError: module 'gmplot' has no attribute 'GoogleMapPlotter'

How can I fix this problem? I just copied the test code to run

I face this issue too.

The Readme should now be updated to show the correct syntax. If it doesn't
solve your problem, can you share the exact piece of code you're trying to
execute?

This is definitely not fixed. I installed and ran the unit test...got the error. Copy and pasted the readme code...got the error. Copied the contents of the gmplot directory into the script directory, got a new error:
from gmplot import gmplot
ImportError: cannot import name gmplot

Ok, let's get this fixed. Can you share your exact commands, including
cloning and any cd'ing, to reproduce the error?

An uninstall/reinstall of the package fixed the issue. :)

authors: LingzhouAo denson share-with-me vgm64


text:
first-time install - Minio error

Followed steps in tutorial and got the following:
mc:  Unable to make bucket minio/outline-bucket. Your previous request to create the named bucket succeeded and you already own it.
Access permission for minio/outline-bucket is set to download

same here

@samuellhwarren did you manage to solve the problem or find a workaround?

No I did not find a solution

repo: vicalloy/outline-docker-compose


text:
chore(main): release 1.3.1

:robot: I have created a release beep boop
1.3.1 (2024-05-12)
🐛 Bugfixes

add armhf to ubuntu oracular (5dc1a8b)
add riscv64 to debian trixie (9b2cc53)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/vicamo/actions-library/releases/tag/v1.3.1 :sunflower:

repo: vicamo/actions-library


text:
🛑 SC storefront shopend is down

In a8c6db1, SC storefront shopend (https://shop.line.me/@024azltq) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SC storefront shopend is back up in 1b64e0c.

repo: vichaos/upptime


text:
Add Dead Product component

Add component for when a product has already been killed.

Closed in latest PR

repo: victorfrye/microsoftgraveyard


text:
Enable array access in _HT*

State
Currently _HT* can only be used to reference arrays as a whole. It is not possible to dig into an array via indexing.
Feature Idea
Enable indexing of arrays in _HT* to be able to dig into array elements when using _HT*. Syntax should be straight forward:
_HT*hull.config.specific.theArray.0

Available  in releases
1.28.15
1.29.8
1.30.1

repo: vidispine/hull


text:
Compilation error - too few arguments to function lxw_worksheet_prepare_chart

Hello, when compiling with the latest libxlswriter the following compilation error happens:
/packages/php-xlswriter/src/xlswriter-1.2.2/kernel/write.c: In function '_prepare_drawings':
/packages/php-xlswriter/src/xlswriter-1.2.2/kernel/write.c:370:13: error: too few arguments to function 'lxw_worksheet_prepare_chart'
             lxw_worksheet_prepare_chart(worksheet, chart_ref_id, drawing_id,
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/xlsxwriter/workbook.h:48:0,
                 from /usr/include/xlsxwriter.h:16,
                 from /packages/php-xlswriter/src/xlswriter-1.2.2/kernel/include.h:23,
                 from /packages/php-xlswriter/src/xlswriter-1.2.2/kernel/write.c:13:
/usr/include/xlsxwriter/worksheet.h:3247:6: note: declared here

PHP versions: 7.0.32, 7.1.24, 7.2.12, 7.3.0RC6
OS: Alpine Linux
php-ext-excel-export version: 1.2.2
libxlsxwriter: 0.8.4

Thank you.

@petk  Have you updated bunled Lib? 🙂

Thank you @viest It works with 1.2.3. Yes, I've used the "system" library (a custom built libxlswriter) and set the --with-libxlsxwriter option and now it works. Somehow, if the libxlswriter is already installed on the system and this configure option is not set it doesn't work. Maybe I've missed something but now it works so thank you for such a quick fix.

Thank you for your issue. 🙂

authors: petk viest

repo: viest/php-ext-excel-export


text:
内部私有化部署场景下证书问题导致sdk无法建立https连接

python的sdk能否增加配置选项，可以手动指定忽略证书错误。

replace the request instance after initializing Vika
import requests
session = requests.Session()
session.verify = False

vika = Vika()

vika.request = session

authors: channelvison mayneyao


text:
update lang on client side navigation

closes #55
This is basically the same as https://github.com/vikejs/vike-react/pull/61
One thing I'd like to remark - how about having getLang not return null, but the default value en since that's what we'll be using as a fallback anyways? Right now, calling getLang from any component would return null, which imo is incorrect since we've set a lang attribute.

I hadn't thought of the user overwriting onRenderClient, which is to be expected.
With that in mind I think I prefer null.

@AurelienLourot yes, That make sense
@4350pChris Thanks 👍

repo: vikejs/vike-vue


text:
Nedaju sa prehravat videa

V zatvorenych clankoch sa nedaju prehrat videa, prehravac nefunguje - napr. https://domov.sme.sk/c/20659773/droba-zavadzal-o-apartmane-od-kocnera.html

Pridana funkcionalita na prehravanie videi v clankoch. Kedze Chrome zial nevie spolahlivo prehravat HD sme.sk videa, takze sa nacitava len ich SD variant. Kvalita medzi SD a HD je v pripade sme.sk zanedbatelna.

repo: viliampucik/nepi-jano


text:
🛑 Booking is down

In 4a29de1, Booking ($SITE_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Booking is back up in 81adefa after 38 minutes.

repo: villekulla-nma/monitor-booking


text:
Major upgrades (1.1.0)

Newly Added:

OpenCV checkerboard detection with subpixel refinement
New "View" abstraction for imgui panes, easily extendable
Added threadpool for handling non-gui related processing
Better UI for ViewRecorder, ViewCornerDetector, ViewRosbagInspector
Added better-enums for imgui combo boxes
Install "priors" for vk suite products
Upgrades:
Better dependency management
No more libcbdetect, poor performance compared to opencv
More efficient processing, made use of C++ move semantics and lesser copies made
Many bug fixes (segfaults, memory issues)

Build failed because of LICENSE (was added to main instead)


text:
error with mksession E946: Cannot make a terminal with running job modifiable: nomodifiable

If you save a session containing a terminal, you get an error code:
E946: Cannot make a terminal with running job modifiable: nomodifiable
Steps:
start vim
open a terminal session with
:vertical terminal
save the session with
:mksession file
Close and then start vim
load the session with
:source file
See that you receive the error
E946: Cannot make a terminal with running job modifiable: nomodifiable
which sends you to the row 373 (more or less) of the session file, where you find the row:
setlocal nomodifiable
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 26 2017 00:51:47)
Included patches: 1-1216
Compiled by
Huge version with GTK2 GUI.  Features included (+) or not (-):

Fixed with patch 8.0.1589

authors: GianniGi brammool

repo: vim/vim

license: Vim