how to use examples/*.yaml  in docker

I'm new to tetragon, after I read the docs,and use docker.
first i use docker run and /usr/bin/tetragon,/usr/bin/tetragon ,Everything is perfect!
then,i use " /usr/bin/tetragon --config-file open_file.yaml",i have copy this file into the container,but it didn't seem to work.
How can I make it work

Hi, can you please past the output of that command? and getting the container logs would be good.
We may also ship some of these examples part of the image to make it easy to run.

Hi, can you please past the output of that command? and getting the container logs would be good.
We may also ship some of these examples part of the image to make it easy to run.

Sorry for my late response,I ran more tests on Tetragon over a few days.There are the following conclusions
1、“tetragon --config-file  open_kill.yaml”,This boot does not allow yaml to take effect
2、use "/usr/bin/tetragon" start tetragon,then use "tetra tracingpolicy add open_kill.yaml",This way yaml works
3、When we run stand-alone or dokcer，Monitoring file reads and writes does not work. However, other configurations such as tcp-connect can take effect
4、in k8s，we can monitoring file reads and writes，such as use sys_write_follow_fd_prefix.yaml
I have some questions:
1、Why cannot I monitor file read and write if I do not rely on k8s，such as use sys_write_follow_fd_prefix.yaml
2、Will tetragon rely on k8s in the future？
3、Is there a way to avoid k8s dependency for the current version

Same issue, any new update?

Hi, can you please past the output of that command? and getting the container logs would be good.
We may also ship some of these examples part of the image to make it easy to run.

Sorry for my late response,I ran more tests on Tetragon over a few days.There are the following conclusions

“tetragon --config-file open_kill.yaml”,This boot does not allow yaml to take effect

First thanks for the report, so as a startup I would suggest you follow this new doc that is being update in the process https://tetragon.cilium.io/docs/
For 1. Are you running tetragon in stadalone mode or docker?  you must ensure that the tracingpolicy file is reachable.
And that open_kill.yaml is assuming pid namespaces and more for k8s and container cases, so can you please check this https://tetragon.cilium.io/docs/reference/tracing-policy/#getting-started-with-tracing-policy and try to reproduce?
Running that with that tracingpolicy
sudo ./tetragon --bpf-lib bpf/objs/ --log-level=trace --config-file open_passwd.yaml

The cat on passwd file produces right output:
"process_kprobe": {
    "process": {
      "exec_id": "OjE3OTEyMDY2MDk3Njc1OjIxNTE5NQ==",
      "pid": 215195,
      "uid": 1000,
      "cwd": "/home/tixxdz/work/station/code/src/github.com/tixxdz/tetragon",
      "binary": "/usr/bin/cat",
      "arguments": "/etc/passwd",
      "flags": "execve clone",
      "start_time": "2023-04-27T14:12:53.096501711Z",
      "auid": 1000,
      "parent_exec_id": "OjE1MzgxNjAwMDAwMDA6MTA5MDA=",
      "refcnt": 1,
      "tid": 215195
    },

use "/usr/bin/tetragon" start tetragon,then use "tetra tracingpolicy add open_kill.yaml",This way yaml works

Great!

When we run stand-alone or dokcer, Monitoring file reads and writes does not work. However, other configurations such as tcp-connect can take effect

It should work, running an unstable image here https://tetragon.cilium.io/docs/getting-started/deployment/container/#unstable-development-versions:
Use same tracingpolicy from that documentation
docker run --name tetragon  -d  --rm -it --pid=host    --cgroupns=host --privileged \
     -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \
     -v $(pwd)/examples/tracingpolicy/etc_pwd.yaml:/etc/tetragon/etc_pwd.yaml \
     quay.io/cilium/tetragon-ci:latest \
     "--config-file=/etc/tetragon/etc_pwd.yaml"

Then on another one as an example to catch the events, feel free to setup logging etc, check tetragon --help, and https://tetragon.cilium.io/docs/getting-started/configuration/
So
docker exec -it tetragon /usr/bin/tetra getevents | tee events.json

Produces:
{
  "process_kprobe": {
    "process": {
      "exec_id": "OjE5ODcxNTUxMjE3MjUyOjIyMzMyMA==",
      "pid": 223320,
      "uid": 1000,
      "cwd": "/home/tixxdz/work/station/code/src/github.com/tixxdz/tetragon",
      "binary": "/usr/bin/cat",
      "arguments": "/etc/passwd",
      "flags": "execve clone",
      "start_time": "2023-04-27T14:45:32.581622218Z",
      "auid": 1000,
      "parent_exec_id": "OjE1MzgxNjAwMDAwMDA6MTA5MDA=",
      "refcnt": 1
    },
    "parent": {
      "exec_id": "OjE1MzgxNjAwMDAwMDA6MTA5MDA=",
      "pid": 10900,
      "uid": 1000,
      "cwd": "/home/tixxdz/work/station/code/src/github.com/tixxdz/tetragon",
      "binary": "/usr/bin/bash",
      "flags": "procFS auid",
      "start_time": "2023-04-27T09:39:59.190402834Z",
      "auid": 1000,
      "parent_exec_id": "Ojc4OTU1MDAwMDAwMDo3NTQy",
      "refcnt": 2
    },
    "function_name": "fd_install",
    "args": [
      {
        "int_arg": 3
      },
      {
        "file_arg": {
          "path": "/etc/passwd"
        }
      }
    ],
    "action": "KPROBE_ACTION_POST"
  },
  "time": "2023-04-27T14:45:32.582854242Z"
}

in k8s，we can monitoring file reads and writes，such as use sys_write_follow_fd_prefix.yaml I have some questions:
1、Why cannot I monitor file read and write if I do not rely on k8s，such as use sys_write_follow_fd_prefix.yaml

Just read about tracingpolicy doc https://tetragon.cilium.io/docs/reference/tracing-policy/ and linux namespaces, maybe the tracingpolicy you are using is selectors based on pid namespaces? and you didn't have any process in pidnamespace?
It should work without k8s , on host standalone or in container mode too monitoring host.

2、Will tetragon rely on k8s in the future

All environments should be supported, events can be captured on the host if k8s is present or no. However if k8s is present we do k8s metadata enrichment to have pods and containers information reported with events.
Just ensure that you tracingpolicy are correct and you don't use selectors that may filter out events for your case. As those are optimized to happen in the kernel.

3、Is there a way to avoid k8s dependency for the current version

There is no dependency on k8s , it is even disabled by default: https://github.com/cilium/tetragon/blob/main/cmd/tetragon/main.go#L589  , for helm charts we do of course explicitly set it ;-)
Hope this helps and sorry for late reply!

I added label documentation for this issue, so we should close it when we have better documentation on how to use yaml tracing policies in docker containers (without k8s)

Same issue, any new update?

Hi @kooriboh please check the above comment , and let us know if you still have problems! Thank you!

I run latest Tetragon version on Rocky 9.1 (ARM64) in standalone mode. Everything works fine with the tcp-connect.yaml as config file. But when I use configuration from sys_write_follow_fd_etc_pwd.yaml or sys_write_follow_fd_prefix.yaml, it didn't seem to work. The logs is still the same as when using tetragon without extra config file.
This is the command I use:
sudo ./tetragon --bpf-lib bpf/objs --config-file examples/tracingpolicy/sys_write_follow_fd_prefix.yaml
This is the syslogs come with the command:
time="2023-04-27T22:48:27+07:00" level=info msg="Starting tetragon" version=v0.10.0-pre.1-25-ga457dcc5
time="2023-04-27T22:48:27+07:00" level=info msg="config settings" config="map[bpf-lib:bpf/objs btf: cilium-bpf: config-dir: config-file:examples/tracingpolicy/sys_write_follow_fd_prefix.yaml cpuprofile: data-cache-size:1024 debug:false disable-kprobe-multi:false enable-cilium-api:false enable-export-aggregation:false enable-k8s-api:false enable-policy-filter:false enable-policy-filter-debug:false enable-process-ancestors:true enable-process-cred:false enable-process-ns:false event-queue-size:10000 export-aggregation-buffer-size:10000 export-aggregation-window-size:15s export-allowlist: export-denylist: export-file-compress:true export-file-max-backups:5 export-file-max-size-mb:10 export-file-rotation-interval:0s export-filename:/var/log/tetragon/tetragon.log export-rate-limit:-1 field-filters: force-large-progs:false force-small-progs:false gops-address: k8s-kubeconfig-path: kernel: log-format:text log-level:info memprofile: metrics-server: netns-dir:/var/run/docker/netns/ pprof-addr: process-cache-size:65536 procfs:/proc/ rb-size:0 rb-size-total:0 release-pinned-bpf:true server-address:unix:///var/run/tetragon/tetragon.sock verbose:0]"
time="2023-04-27T22:48:27+07:00" level=info msg="BPF: successfully released pinned BPF programs and maps" bpf-dir=/sys/fs/bpf/tetragon
time="2023-04-27T22:48:27+07:00" level=info msg="BTF discovery: default kernel btf file found" btf-file=/sys/kernel/btf/vmlinux
time="2023-04-27T22:48:27+07:00" level=info msg="sensor controller waiting on channel"
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroup mode detection succeeded" cgroup.fs=/sys/fs/cgroup cgroup.mode="Unified mode (Cgroupv2)"
time="2023-04-27T22:48:27+07:00" level=info msg="Supported cgroup controller 'memory' is active on the system" cgroup.controller.hierarchyID=0 cgroup.controller.index=4 cgroup.controller.name=memory cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Supported cgroup controller 'pids' is active on the system" cgroup.controller.hierarchyID=0 cgroup.controller.index=11 cgroup.controller.name=pids cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Supported cgroup controller 'cpuset' is active on the system" cgroup.controller.hierarchyID=0 cgroup.controller.index=0 cgroup.controller.name=cpuset cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroupv2 supported controllers detected successfully" cgroup.controllers="[memory pids]" cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroupv2 controller 'memory' will be used as a fallback for the default hierarchy" cgroup.controller.hierarchyID=0 cgroup.controller.index=4 cgroup.controller.name=memory cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroupv2 hierarchy validated successfully" cgroup.fs=/sys/fs/cgroup cgroup.path=/sys/fs/cgroup/user.slice/user-0.slice/session-3.scope
time="2023-04-27T22:48:27+07:00" level=info msg="Deployment mode detection succeeded" cgroup.fs=/sys/fs/cgroup deployment.mode="systemd user session"
time="2023-04-27T22:48:27+07:00" level=info msg="Updated TetragonConf map successfully" NSPID=1495 cgroup.controller.hierarchyID=0 cgroup.controller.index=4 cgroup.controller.name=memory cgroup.fs.magic=Cgroupv2 confmap-update=tg_conf_map deployment.mode="systemd user session" log.level=info
time="2023-04-27T22:48:27+07:00" level=info msg="Disabling Kubernetes API"
time="2023-04-27T22:48:27+07:00" level=info msg="Disabling Cilium API"
time="2023-04-27T22:48:27+07:00" level=info msg="Starting process manager" enableCilium=false enableK8s=false enableProcessCred=false enableProcessNs=false
time="2023-04-27T22:48:27+07:00" level=info msg="Starting JSON exporter" logger="&{/var/log/tetragon/tetragon.log 10 0 5 false true -rw------- 0 <nil> {0 0} <nil> {0 {0 0}}}" request=
time="2023-04-27T22:48:27+07:00" level=info msg="Exporter configuration" enabled=true fileName=/var/log/tetragon/tetragon.log
time="2023-04-27T22:48:27+07:00" level=info msg="BPF: found active BPF resources" bpf-dir=/sys/fs/bpf/tetragon pinned-bpf="[tg_conf_map]"
time="2023-04-27T22:48:27+07:00" level=info msg="BTF file: using metadata file" metadata=/sys/kernel/btf/vmlinux
time="2023-04-27T22:48:27+07:00" level=info msg="Loading sensor" name=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="Loading kernel version 5.14.0"
time="2023-04-27T22:48:27+07:00" level=info msg="Starting gRPC server" address=/var/run/tetragon/tetragon.sock protocol=unix
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=execve_map path=/sys/fs/bpf/tetragon/execve_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=execve_map_stats path=/sys/fs/bpf/tetragon/execve_map_stats sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=execve_calls path=/sys/fs/bpf/tetragon/execve_calls sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=names_map path=/sys/fs/bpf/tetragon/names_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=tcpmon_map path=/sys/fs/bpf/tetragon/tcpmon_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=tg_conf_map path=/sys/fs/bpf/tetragon/tg_conf_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="Loading BPF program" Program=bpf/objs/bpf_exit.o Type=kprobe
time="2023-04-27T22:48:27+07:00" level=info msg="Loading BPF program" Program=bpf/objs/bpf_fork.o Type=kprobe
time="2023-04-27T22:48:27+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_execve_event_v53.o Type=execve
time="2023-04-27T22:48:27+07:00" level=info msg="Read ProcFS /proc/ appended 35/173 entries"
time="2023-04-27T22:48:27+07:00" level=warning msg="Procfs execve event pods/ identifier error" error="open /proc/0/cgroup: no such file or directory"
time="2023-04-27T22:48:27+07:00" level=info msg="Loaded BPF maps and events for sensor successfully" sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="sensor controller starts"
time="2023-04-27T22:48:27+07:00" level=info msg="Available sensors" sensors=
time="2023-04-27T22:48:27+07:00" level=info msg="Registered sensors (policy-handlers)" policy-handlers="uprobe sensor, loader sensor, tracing"
time="2023-04-27T22:48:27+07:00" level=info msg="Registered probe types" types="generic_uprobe, loader, execve, generic_kprobe, generic_tracepoint"
time="2023-04-27T22:48:27+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="type (file) of argument 1 does not match spec type (file)\n" sensor=gkp-sensor-1
time="2023-04-27T22:48:27+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="could not get the function prototype for __arm64_sys_close: arguments will not be verified" sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="could not get the function prototype for __arm64_sys_read: arguments will not be verified" sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="could not get the function prototype for __arm64_sys_write: arguments will not be verified" sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> fd_install" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_close" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_read" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_write" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="BTF file: using metadata file" metadata=/sys/kernel/btf/vmlinux
time="2023-04-27T22:48:28+07:00" level=info msg="Loading sensor" name=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="Loading kernel version 5.14.0"
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-retprobe_config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:31+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> fd_install"
time="2023-04-27T22:48:31+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:33+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_close"
time="2023-04-27T22:48:33+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:35+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_read"
time="2023-04-27T22:48:35+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_retkprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:35+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_retkprobe_v53.o -> __arm64_sys_read"
time="2023-04-27T22:48:35+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:37+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_write"
time="2023-04-27T22:48:37+07:00" level=info msg="Loaded BPF maps and events for sensor successfully" sensor=gkp-sensor-1
time="2023-04-27T22:48:37+07:00" level=info msg="Perf ring buffer size (bytes)" percpu=69632 total=139264
time="2023-04-27T22:48:37+07:00" level=info msg="Listening for events..."

And this is the logs from /var/log/tetragon/tetragon.log when I edit /etc/passwd using nano:
{"process_exec":{"process":{"exec_id":"OjE4Mjg1NTUwNjU5OTc6MTUyNA==","pid":1524,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/nano","arguments":"/etc/passwd","flags":"execve clone","start_time":"2023-04-27T15:53:11.199366909Z","auid":0,"parent_exec_id":"OjM1NjQwMDAwMDAwOjEyNzI="},"parent":{"exec_id":"OjM1NjQwMDAwMDAwOjEyNzI=","pid":1272,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/bash","flags":"procFS auid","start_time":"2023-04-27T15:23:18.284299787Z","auid":0,"parent_exec_id":"OjI1MTIwMDAwMDAwOjEyMjY=","refcnt":3}},"time":"2023-04-27T15:53:11.199431160Z"}
{"process_exit":{"process":{"exec_id":"OjE4Mjg1NTUwNjU5OTc6MTUyNA==","pid":1524,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/nano","arguments":"/etc/passwd","flags":"execve clone","start_time":"2023-04-27T15:53:11.199366909Z","auid":0,"parent_exec_id":"OjM1NjQwMDAwMDAwOjEyNzI="},"parent":{"exec_id":"OjM1NjQwMDAwMDAwOjEyNzI=","pid":1272,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/bash","flags":"procFS auid","start_time":"2023-04-27T15:23:18.284299787Z","auid":0,"parent_exec_id":"OjI1MTIwMDAwMDAwOjEyMjY=","refcnt":1},"time":"2023-04-27T15:53:19.886299Z"},"time":"2023-04-27T15:53:19.886339999Z"}

Thank you for your reply and looking forward to hearing from you!

Same issue, any new update?

Hi @kooriboh please check the above comment , and let us know if you still have problems! Thank you!

I run latest Tetragon version on Rocky 9.1 (ARM64) in standalone mode. Everything works fine with the tcp-connect.yaml as config file. But when I use configuration from sys_write_follow_fd_etc_pwd.yaml or sys_write_follow_fd_prefix.yaml, it didn't seem to work. The logs is still the same as when using tetragon without extra config file.
This is the command I use:
sudo ./tetragon --bpf-lib bpf/objs --config-file examples/tracingpolicy/sys_write_follow_fd_prefix.yaml
This is the syslogs come with the command:
time="2023-04-27T22:48:27+07:00" level=info msg="Starting tetragon" version=v0.10.0-pre.1-25-ga457dcc5
time="2023-04-27T22:48:27+07:00" level=info msg="config settings" config="map[bpf-lib:bpf/objs btf: cilium-bpf: config-dir: config-file:examples/tracingpolicy/sys_write_follow_fd_prefix.yaml cpuprofile: data-cache-size:1024 debug:false disable-kprobe-multi:false enable-cilium-api:false enable-export-aggregation:false enable-k8s-api:false enable-policy-filter:false enable-policy-filter-debug:false enable-process-ancestors:true enable-process-cred:false enable-process-ns:false event-queue-size:10000 export-aggregation-buffer-size:10000 export-aggregation-window-size:15s export-allowlist: export-denylist: export-file-compress:true export-file-max-backups:5 export-file-max-size-mb:10 export-file-rotation-interval:0s export-filename:/var/log/tetragon/tetragon.log export-rate-limit:-1 field-filters: force-large-progs:false force-small-progs:false gops-address: k8s-kubeconfig-path: kernel: log-format:text log-level:info memprofile: metrics-server: netns-dir:/var/run/docker/netns/ pprof-addr: process-cache-size:65536 procfs:/proc/ rb-size:0 rb-size-total:0 release-pinned-bpf:true server-address:unix:///var/run/tetragon/tetragon.sock verbose:0]"
time="2023-04-27T22:48:27+07:00" level=info msg="BPF: successfully released pinned BPF programs and maps" bpf-dir=/sys/fs/bpf/tetragon
time="2023-04-27T22:48:27+07:00" level=info msg="BTF discovery: default kernel btf file found" btf-file=/sys/kernel/btf/vmlinux
time="2023-04-27T22:48:27+07:00" level=info msg="sensor controller waiting on channel"
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroup mode detection succeeded" cgroup.fs=/sys/fs/cgroup cgroup.mode="Unified mode (Cgroupv2)"
time="2023-04-27T22:48:27+07:00" level=info msg="Supported cgroup controller 'memory' is active on the system" cgroup.controller.hierarchyID=0 cgroup.controller.index=4 cgroup.controller.name=memory cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Supported cgroup controller 'pids' is active on the system" cgroup.controller.hierarchyID=0 cgroup.controller.index=11 cgroup.controller.name=pids cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Supported cgroup controller 'cpuset' is active on the system" cgroup.controller.hierarchyID=0 cgroup.controller.index=0 cgroup.controller.name=cpuset cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroupv2 supported controllers detected successfully" cgroup.controllers="[memory pids]" cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroupv2 controller 'memory' will be used as a fallback for the default hierarchy" cgroup.controller.hierarchyID=0 cgroup.controller.index=4 cgroup.controller.name=memory cgroup.fs=/sys/fs/cgroup
time="2023-04-27T22:48:27+07:00" level=info msg="Cgroupv2 hierarchy validated successfully" cgroup.fs=/sys/fs/cgroup cgroup.path=/sys/fs/cgroup/user.slice/user-0.slice/session-3.scope
time="2023-04-27T22:48:27+07:00" level=info msg="Deployment mode detection succeeded" cgroup.fs=/sys/fs/cgroup deployment.mode="systemd user session"
time="2023-04-27T22:48:27+07:00" level=info msg="Updated TetragonConf map successfully" NSPID=1495 cgroup.controller.hierarchyID=0 cgroup.controller.index=4 cgroup.controller.name=memory cgroup.fs.magic=Cgroupv2 confmap-update=tg_conf_map deployment.mode="systemd user session" log.level=info
time="2023-04-27T22:48:27+07:00" level=info msg="Disabling Kubernetes API"
time="2023-04-27T22:48:27+07:00" level=info msg="Disabling Cilium API"
time="2023-04-27T22:48:27+07:00" level=info msg="Starting process manager" enableCilium=false enableK8s=false enableProcessCred=false enableProcessNs=false
time="2023-04-27T22:48:27+07:00" level=info msg="Starting JSON exporter" logger="&{/var/log/tetragon/tetragon.log 10 0 5 false true -rw------- 0 <nil> {0 0} <nil> {0 {0 0}}}" request=
time="2023-04-27T22:48:27+07:00" level=info msg="Exporter configuration" enabled=true fileName=/var/log/tetragon/tetragon.log
time="2023-04-27T22:48:27+07:00" level=info msg="BPF: found active BPF resources" bpf-dir=/sys/fs/bpf/tetragon pinned-bpf="[tg_conf_map]"
time="2023-04-27T22:48:27+07:00" level=info msg="BTF file: using metadata file" metadata=/sys/kernel/btf/vmlinux
time="2023-04-27T22:48:27+07:00" level=info msg="Loading sensor" name=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="Loading kernel version 5.14.0"
time="2023-04-27T22:48:27+07:00" level=info msg="Starting gRPC server" address=/var/run/tetragon/tetragon.sock protocol=unix
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=execve_map path=/sys/fs/bpf/tetragon/execve_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=execve_map_stats path=/sys/fs/bpf/tetragon/execve_map_stats sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=execve_calls path=/sys/fs/bpf/tetragon/execve_calls sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=names_map path=/sys/fs/bpf/tetragon/names_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=tcpmon_map path=/sys/fs/bpf/tetragon/tcpmon_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="tetragon, map loaded." map=tg_conf_map path=/sys/fs/bpf/tetragon/tg_conf_map sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="Loading BPF program" Program=bpf/objs/bpf_exit.o Type=kprobe
time="2023-04-27T22:48:27+07:00" level=info msg="Loading BPF program" Program=bpf/objs/bpf_fork.o Type=kprobe
time="2023-04-27T22:48:27+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_execve_event_v53.o Type=execve
time="2023-04-27T22:48:27+07:00" level=info msg="Read ProcFS /proc/ appended 35/173 entries"
time="2023-04-27T22:48:27+07:00" level=warning msg="Procfs execve event pods/ identifier error" error="open /proc/0/cgroup: no such file or directory"
time="2023-04-27T22:48:27+07:00" level=info msg="Loaded BPF maps and events for sensor successfully" sensor=__base__
time="2023-04-27T22:48:27+07:00" level=info msg="sensor controller starts"
time="2023-04-27T22:48:27+07:00" level=info msg="Available sensors" sensors=
time="2023-04-27T22:48:27+07:00" level=info msg="Registered sensors (policy-handlers)" policy-handlers="uprobe sensor, loader sensor, tracing"
time="2023-04-27T22:48:27+07:00" level=info msg="Registered probe types" types="generic_uprobe, loader, execve, generic_kprobe, generic_tracepoint"
time="2023-04-27T22:48:27+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="type (file) of argument 1 does not match spec type (file)\n" sensor=gkp-sensor-1
time="2023-04-27T22:48:27+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="could not get the function prototype for __arm64_sys_close: arguments will not be verified" sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="could not get the function prototype for __arm64_sys_read: arguments will not be verified" sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=warning msg="Kprobe spec pre-validation failed, but will continue with loading" error="could not get the function prototype for __arm64_sys_write: arguments will not be verified" sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> fd_install" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_close" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_read" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="Added generic kprobe sensor: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_write" flags=none
time="2023-04-27T22:48:28+07:00" level=info msg="BTF file: using metadata file" metadata=/sys/kernel/btf/vmlinux
time="2023-04-27T22:48:28+07:00" level=info msg="Loading sensor" name=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="Loading kernel version 5.14.0"
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-0-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-1-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:28+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-2-retprobe_config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=fdinstall_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-fdinstall_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=config_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-config_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=kprobe_calls path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-kp_calls sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=filter_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-filter_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=argfilter_maps path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-argfilter_maps sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=retprobe_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-retprobe_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=process_call_heap path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-process_call_heap sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="tetragon, map loaded." map=sel_names_map path=/sys/fs/bpf/tetragon/gkp-sensor-1-gkp-3-sel_names_map sensor=gkp-sensor-1
time="2023-04-27T22:48:29+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:31+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> fd_install"
time="2023-04-27T22:48:31+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:33+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_close"
time="2023-04-27T22:48:33+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:35+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_read"
time="2023-04-27T22:48:35+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_retkprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:35+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_retkprobe_v53.o -> __arm64_sys_read"
time="2023-04-27T22:48:35+07:00" level=info msg="Loading registered BPF probe" Program=bpf/objs/bpf_generic_kprobe_v53.o Type=generic_kprobe
time="2023-04-27T22:48:37+07:00" level=info msg="Loaded generic kprobe program: bpf/objs/bpf_generic_kprobe_v53.o -> __arm64_sys_write"
time="2023-04-27T22:48:37+07:00" level=info msg="Loaded BPF maps and events for sensor successfully" sensor=gkp-sensor-1
time="2023-04-27T22:48:37+07:00" level=info msg="Perf ring buffer size (bytes)" percpu=69632 total=139264
time="2023-04-27T22:48:37+07:00" level=info msg="Listening for events..."

And this is the logs from /var/log/tetragon/tetragon.log when I edit /etc/passwd using nano:
{"process_exec":{"process":{"exec_id":"OjE4Mjg1NTUwNjU5OTc6MTUyNA==","pid":1524,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/nano","arguments":"/etc/passwd","flags":"execve clone","start_time":"2023-04-27T15:53:11.199366909Z","auid":0,"parent_exec_id":"OjM1NjQwMDAwMDAwOjEyNzI="},"parent":{"exec_id":"OjM1NjQwMDAwMDAwOjEyNzI=","pid":1272,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/bash","flags":"procFS auid","start_time":"2023-04-27T15:23:18.284299787Z","auid":0,"parent_exec_id":"OjI1MTIwMDAwMDAwOjEyMjY=","refcnt":3}},"time":"2023-04-27T15:53:11.199431160Z"}
{"process_exit":{"process":{"exec_id":"OjE4Mjg1NTUwNjU5OTc6MTUyNA==","pid":1524,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/nano","arguments":"/etc/passwd","flags":"execve clone","start_time":"2023-04-27T15:53:11.199366909Z","auid":0,"parent_exec_id":"OjM1NjQwMDAwMDAwOjEyNzI="},"parent":{"exec_id":"OjM1NjQwMDAwMDAwOjEyNzI=","pid":1272,"uid":0,"cwd":"/root/tetragon/examples/tracingpolicy","binary":"/usr/bin/bash","flags":"procFS auid","start_time":"2023-04-27T15:23:18.284299787Z","auid":0,"parent_exec_id":"OjI1MTIwMDAwMDAwOjEyMjY=","refcnt":1},"time":"2023-04-27T15:53:19.886299Z"},"time":"2023-04-27T15:53:19.886339999Z"}

Thank you for your reply and looking forward to hearing from you!

Please check again this repsonse: https://github.com/cilium/tetragon/issues/699#issuecomment-1525850662 as it explains why you are not seing events. That tracing policy catch events in pid namespaces, are you generating these events from a pid namespace?
Otherwise try this simple one https://tetragon.cilium.io/docs/reference/tracing-policy/#getting-started-with-tracing-policy

Sorry, my fault for not paying attention to that. I tested again with your instructions and everything works fine. Thanks for your support.


Pass args forward to Spring application.

This should fix the docker / CI build…
I am unsure how that worked before, but in anyway, the environment is not forwarded. I guess other stores like Mongo are affected as well when they use an external docker or database instance.
Paging @christophstrobl here as he notified me about the issue.

Could you share more about how this could fix the flaky test we have on https://ci.spring.io/teams/spring-graalvm-native/pipelines/spring-graalvm-native/jobs/build-20.3-dev-java11-samples/builds/21?

I haven't looked into your CI setup…
With the  Docker compose setup things will fail as they depend on a working environment support
https://github.com/spring-projects-experimental/spring-graalvm-native/blob/master/spring-graalvm-native-samples/data-neo4j/docker-compose.yml#L13
You see the environment variable pointing to the Neo4j host.
With the development container: I am unsure. Localhost should work and as far as I understand, the examples run inside the same dev container, right?
It could be that the waiting here isn't long enough https://github.com/spring-projects-experimental/spring-graalvm-native/blob/master/spring-graalvm-native-samples/data-neo4j/src/main/java/com/example/data/neo4j/CLR.java#L177-L187
However https://ci.spring.io/teams/spring-graalvm-native/pipelines/spring-graalvm-native/jobs/build-20.3-dev-java11-samples/builds/21#L5fa4a29d:1984  this line speaks different… The connection succeeded but maybe the Job got killed afterwards?
I cannot make more sense out of the output… It just stops there. Is it truncated somehow?

I have been on the machine and found following output:

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.4.0)

2020-11-24 14:28:59.244  INFO 9094 --- [           main] com.example.data.neo4j.Neo4jApplication  : Starting Neo4jApplication using Java 11.0.9 on 0a94c5d2-6fc0-4465-43ac-eb9044cf3428 with PID 9094 (/tmp/build/80754af9/spring-graalvm-native/spring-graalvm-native-samples/data-neo4j/target/data-neo4j started by root in /tmp/build/80754af9/spring-graalvm-native/spring-graalvm-native-samples/data-neo4j)
2020-11-24 14:28:59.244  INFO 9094 --- [           main] com.example.data.neo4j.Neo4jApplication  : The following profiles are active: ci
2020-11-24 14:28:59.260  INFO 9094 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data Neo4j repositories in DEFAULT mode.
2020-11-24 14:28:59.261  INFO 9094 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 0 ms. Found 1 Neo4j repository interfaces.
2020-11-24 14:28:59.272  INFO 9094 --- [           main] org.neo4j.driver.Driver                  : Direct driver instance 397189216 created for server address localhost:7687
2020-11-24 14:28:59.283  INFO 9094 --- [           main] tionInformation$PropertyDescriptorSource : Couldn't read class metadata for interface com.example.data.neo4j.OrderProjection. Input property calculation might fail!
2020-11-24 14:28:59.287  INFO 9094 --- [           main] com.example.data.neo4j.Neo4jApplication  : Started Neo4jApplication in 0.052 seconds (JVM running for 0.054)
2020-11-24 14:28:59.288  WARN 9094 --- [o4jDriverIO-2-1] o.n.d.i.s.i.n.channel.DefaultChannelId   : Failed to find the current process ID from ''; using a random value: -1163026406
Deleted 0 nodes and 0 relationships.

---- INT REPO ----
-----------------

---- FIND ALL ----

And the grep is done on QUERY BY EXAMPLE so that's an expected failure.
The same run on my laptop or when the CI is green is:

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.4.0)

2020-11-25 10:43:04.073  INFO 1346 --- [           main] com.example.data.neo4j.Neo4jApplication  : Starting Neo4jApplication using Java 11.0.9 on docker with PID 1346 (/home/seb/spring-graalvm-native/spring-graalvm-native-samples/data-neo4j/target/data-neo4j started by seb in /home/seb/spring-graalvm-native/spring-graalvm-native-samples/data-neo4j)
2020-11-25 10:43:04.073  INFO 1346 --- [           main] com.example.data.neo4j.Neo4jApplication  : The following profiles are active: ci
2020-11-25 10:43:04.081  INFO 1346 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data Neo4j repositories in DEFAULT mode.
2020-11-25 10:43:04.081  INFO 1346 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 0 ms. Found 1 Neo4j repository interfaces.
2020-11-25 10:43:04.087  INFO 1346 --- [           main] org.neo4j.driver.Driver                  : Direct driver instance 401198814 created for server address localhost:7687
2020-11-25 10:43:04.095  INFO 1346 --- [           main] tionInformation$PropertyDescriptorSource : Couldn't read class metadata for interface com.example.data.neo4j.OrderProjection. Input property calculation might fail!
2020-11-25 10:43:04.098  INFO 1346 --- [           main] com.example.data.neo4j.Neo4jApplication  : Started Neo4jApplication in 0.029 seconds (JVM running for 0.03)
2020-11-25 10:43:04.099  WARN 1346 --- [o4jDriverIO-2-1] o.n.d.i.s.i.n.channel.DefaultChannelId   : Failed to find the current process ID from ''; using a random value:<PHONE_NUMBER>
Deleted 0 nodes and 0 relationships.

---- INT REPO ----
-----------------

---- FIND ALL ----
Order{id='48687cd5-49f1-4f3d-9941-567c380d000b', customerId='c42', orderDate=Wed Nov 25 10:43:04 GMT 2020, items=[LineItem{id=3, caption='p3', price=5.33, quantity=1}, LineItem{id=2, caption='p2', price=0.87, quantity=2}, LineItem{id=1, caption='p1', price=1.23, quantity=1}]}
-----------------

---- Paging / Sorting ----
sortedByCustomer: [Order{id='dd90d378-4a00-4424-90fe-dac10dbf6907', customerId='b12', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=1, caption='p1', price=1.23, quantity=1}]}, Order{id='5011275f-ac1f-4da2-9184-596485377801', customerId='b12', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=1, caption='p1', price=1.23, quantity=1}]}, Order{id='e0043a88-e92a-4e86-8abc-8533c15fce08', customerId='c42', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=1, caption='p1', price=1.23, quantity=1}]}, Order{id='e4463544-744e-4e1c-a33a-af15efcb364f', customerId='c42', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=2, caption='p2', price=0.87, quantity=2}]}, Order{id='66848a75-3b90-41f1-8f93-2eb0a2cfa35b', customerId='c42', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=3, caption='p3', price=5.33, quantity=1}]}]
c42_page0: Page 1 of 2 containing com.example.data.neo4j.Order instances
c42_page1: Page 2 of 2 containing com.example.data.neo4j.Order instances
c42_slice0: Slice 0 containing com.example.data.neo4j.Order instances
-----------------

---- PART TREE QUERY ----
Order{id='e9ca8a6b-60f5-49ff-b74d-8fe9d80e84d4', customerId='c42', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=3, caption='p3', price=5.33, quantity=1}, LineItem{id=2, caption='p2', price=0.87, quantity=2}, LineItem{id=1, caption='p1', price=1.23, quantity=1}]}
-----------------

---- ANNOTATED QUERY ----
Order{id='701c669b-f964-40c1-92a3-1dffd5882137', customerId='c42', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[]}
-----------------

---- CUSTOM IMPLEMENTATION ----
invoice: Invoice{orderId='null', taxAmount=1.5770000000000002, netAmount=8.3, totalAmount=9.877, items=[]}
-----------------

---- RESULT PROJECTION ----
OrderProjection($Proxy251){id=c567f4c4-837d-4aa5-9149-6b2595bfa040, customerId=c42}
-----------------

---- QUERY BY EXAMPLE ----
result: [Order{id='24345030-340e-4ace-b398-fa6a1df3274a', customerId='c42', orderDate=Wed Nov 25 10:43:05 GMT 2020, items=[LineItem{id=1, caption='p1', price=1.23, quantity=1}]}]
-----------------

@christophstrobl @michael-simons Any thoughts on the reason of the failure based on those logs?

I have created #384 dedicated issue and will ignore it on the CI for now since today build is also broken.


Replace the legacy Foomedical chat widget with our own widget

Currently, the FooMedical messages page has a custom component.

Foomedical Chat widget: https://foomedical.com/messages

We would like to replace this with our standard React component. Medplum Base Chat React component https://storybook.medplum.com/?path=/story/medplum-chat-basechat--basic

[ ] https://foomedical.com/messages renders a page with a single table

[ ] 1 row per Practitioner resource in the system
[ ] 1 columns

[ ] Practitioner name

[ ] Clicking on a row navigates to https://foomedical.com/messages/:practitionerId
[ ] At https://foomedical.com/messages/:practitionerId, show a chat widget, with the following query

sender=${getReferenceString(profile)},Practitioner/${:practitionerId}&recipient=${getReferenceString(profile)},Practitioner/${:practitionerId}


The nonlinear sensor fusion demo is broken

The inference is broken in the example https://biaslab.github.io/RxInfer.jl/stable/examples/Nonlinear Sensor Fusion/
Check the plots with the inference results

@bvdmitri @albertpod
I am near to fixing it. There is a super stupid one (to remove the optional check on the proper messages and the plots will be correct). But It's possible to fix it by tuning with CVI hyperparameters: also, I think it's valuable because we will have a clear example to the user that hyperparameters are important.
I expect to end it to 24.02.2023.

Please update the end date of this fix ;)

@albertpod I will end the fix at 06.02.2023.

@albertpod Sure, I meant March not February.


1.4: Add federation docs

For user guides:
We have some of them at https://github.com/kelseyhightower/kubernetes-cluster-federation/tree/master/labs.
Things we need to do (as pointed out by @quinton-hoole ):

[ ] Port them over to kubernetes.io
[ ] Talk about federated Namespaces too.
[ ] We also need to cover federated Events, perhaps in the context of troubleshooting.
[ ] Adding a section on Troubleshooting would be good.
[ ] While these tutorials/labs are great as a minimal step by step guide to getting a given thing (e.g. a federated replicaset) working, they don't talk much about why you would want to do this, and what other sorts of things one can achieve with these building blocks.  I think it would be a good idea to add some of that, as well as some illustrations of things like what happens if a cluster goes down, or all of the pods in a given cluster are unschedulable.
[ ] We need to reconcile the use of the word "Federation"  vs "Federated".  They're used somewhat interchangably in our docs.  I suggest standardizing on using "Federated" to describe the API objects (Federated Replicaset, Federated Service etc), and "Federation" to describe the control plane and it's components (e.g. "Federation API Server", "Federation Controller Manager" etc).

For auto-generated docs:

[x] Add auto generated docs for federation binaries (apiserver and control plane): https://github.com/kubernetes/kubernetes.github.io/pull/983, @nikhiljindal
[x] Add API reference docs: https://github.com/kubernetes/kubernetes/pull/31759, @nikhiljindal

cc @kubernetes/sig-cluster-federation @kelseyhightower @kshafiee

@kubernetes/docs @jaredbhatti @devin-donnelly Any easy way to port over https://github.com/kelseyhightower/kubernetes-cluster-federation/tree/master/labs to kubernetes.io?

Have sent https://github.com/kubernetes/kubernetes.github.io/pull/1224 for user guides for events and namespaces.
Have also sent https://github.com/kubernetes/kubernetes.github.io/pull/1222 to surface federation generated docs on the left side navigation panel.
Re: federated and federation: Yes we need to resolve it. I am in favor of just using federation everywhere.
For ex: federation events. federated events doesnt sound right especially because they are not even synced to underlying clusters :) They are just events in the federation control plane.
Also, we call a replicaset in kubernetes cluster, a "kubernetes replica set" not a "kuberneted" or "kubernetized" replicaset.
However, if others feel strongly about calling them "federated resources" instead of "federation resources", I am fine with it. (I am by no means an english expert :)
But we should resolve it soon.
@quinton-hoole @madhusudancs

Thanks Nikhil
I think we can debate the "federated" vs "federation" thing after the
release. For now, I suggest that we go with "Federation" for things
directly related to the control plane (including events, where I totally
agree with you, "Federated" is inappropriate), and "Federated" for things
that span multiple clusters (ReplicaSets, Services etc).
I feel reasonably strongly about this on the basis of grammatical
correctness and semantic accuracy, although I will admit that some people
will probably be unsure about when to use which of the two words, and will
probably write the incorrect one from time to time.  So that would motivate
for only using one of the two terms, and sticking with it, even if it's not
strictly speaking correct.
Either way, we will have a lot of legacy documentation to go through and
correct if we change from the two separate terms ("Federated" and
"Federation") to just one, consistently. I'd be happy to do that, but lets
keep what we have for now, and change it holistically if we decide to,
after the release.
Sound good?
Q
On Tue, Sep 13, 2016 at 6:52 PM, Nikhil Jindal<EMAIL_ADDRESS>wrote:

Have sent #1224
https://github.com/kubernetes/kubernetes.github.io/pull/1224 for user
guides for events and namespaces.
Have also sent #1222
https://github.com/kubernetes/kubernetes.github.io/pull/1222 to surface
federation generated docs on the left side navigation panel.
Re: federated and federation: Yes we need to resolve it. I am in favor of
just using federation everywhere.
For ex: federation events. federated events doesnt sound right especially
because they are not even synced to underlying clusters :) They are just
events in the federation control plane.
Also, we call a replicaset in kubernetes cluster, a "kubernetes replica
set" not a "kuberneted" or "kubernetized" replicaset.
However, if others feel strongly about calling them "federated resources"
instead of "federation resources", I am fine with it. (I am by no means an
english expert :)
But we should resolve it soon.
@quinton-hoole https://github.com/quinton-hoole @madhusudancs
https://github.com/madhusudancs
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubernetes.github.io/issues/1215#issuecomment-246882162,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ6NAYsnSmbQe5jgZU8-5XtVTEfPiPsqks5qp1NsgaJpZM4J7KcI
.

@nikhiljindal @kelseyhightower I will start writing the full user guide for Ingress (along the lines of what I did for Federated Services now.  I hope to have a reasonably final draft ready by the end of today.

I think we can debate the "federated" vs "federation" thing after the
release. For now, I suggest that we go with "Federation" for things
directly related to the control plane (including events, where I totally
agree with you, "Federated" is inappropriate), and "Federated" for things
that span multiple clusters (ReplicaSets, Services etc).
I feel reasonably strongly about this on the basis of grammatical
correctness and semantic accuracy, although I will admit that some people
will probably be unsure about when to use which of the two words, and will
probably write the incorrect one from time to time.  So that would motivate
for only using one of the two terms, and sticking with it, even if it's not
strictly speaking correct.
Either way, we will have a lot of legacy documentation to go through and
correct if we change from the two separate terms ("Federated" and
"Federation") to just one, consistently. I'd be happy to do that, but lets
keep what we have for now, and change it holistically if we decide to,
after the release.
Sound good?

Yes, sounds good. thx

@nikhiljindal , @quinton-hoole , do we have anything to cover Federated Secrets and Federated ReplicaSet?

I am going to send a PR today

All federation docs are now available on k8s.io


Change if conditions to allow short and shortres

In the original eval.py the short chunk CNN is presumably referred to by an older name bocnn and bocnn_res in the model type. So the eval.py function is not compatible with the model.py and solver.py arguments which accepts short and short_res as arguments for the model type.

Thank you for reporting this!


Close icon in search, misses a label for accessibility

The "X" of the search box should have a label for better accessibility
English "Reset search field"
Deutsch "Suchfeld zurücksetzen"
French: "Réinitialiser le champ de recherche"

Please put this label also in the search of the guideline itself
Please update the release notes, for this
https://swiss.github.io/styleguide/de/header.html#02-header-04-site-search

NVDA Reader does not read the span-tag, and it's not accessible with the keyboard


Add DUNS and UEID ids from NIH API to ROR

Update our copy of the ROR table and add a DUNS and UEID column to store the federal id for the org.
Write a script that calls the NIH API searching in batches of n-records where the search criteria is:
{
  "criteria": {
    "org_names": [
      "UNIVERSITY OF CALIFORNIA, DAVIS",
      "STANFORD"
    ]
  },
  "include_fields": [
    "Organization"
  ]
}

This should return something like:
"organization": {
  "org_name": "UNIVERSITY OF CALIFORNIA AT DAVIS",
  "org_city": "DAVIS",
  "org_country": "UNITED STATES",
  "org_state": "CA",
  "dept_type": "NEUROLOGY",
  "org_duns": [
     "047120084"
   ],
   "org_ueis": [
     "TX2DAGQPENZ5"
   ],
   "primary_duns": "047120084",
   "primary_uei": "TX2DAGQPENZ5",
   "org_fips": "US",
   "org_ipf_code": "577503",
   "org_zipcode": "956186153",
   "external_org_id": 577503
 }

We can then compare the results to the ROR data we have:
{
  "name": "University of Wollongong",
  "acronyms": ["UOW"],
  "aliases": ["Wollongong University"],
  "country": {
    "country_code": "AU",
    "country_name": "Australia"
  }
}

Just update DMP creation to do a lookup on Project/Award ids and connect the UEID and DUNS to the ROR record. Will require those fields be added to the ROR table


Create the Subscriber Form - Part II Chapter

Create the Model section:
The tutorial states that we have to add admin.autodiscover() before the definition of urlpatterns.
The docs state that this usage is no longer needed:
https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.autodiscover
Also here:
https://docs.djangoproject.com/en/1.7/intro/tutorial03/#write-your-first-view
I'm wondering if there is a reason you added that line or you simply didn't know about the change.
Thanks for the tutorial, it's very well written, i think if you make it open source, people will show you gratitude by helping you fix some mistakes or even help you improve some parts.

Thanks for pointing that out Hassen. That was an oversight on my part. I started building this in 1.6 and then upgraded it to 1.7. I will fix that and update the content.

Great!


Usage based Rate Limiting (Counting from response header values)

cc @zirain @missBerg

xref: https://github.com/envoyproxy/ratelimit/pull/752

can we update the ratelimit filter in Envoy https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting#per-connection-or-per-http-request-rate-limiting to regenerate ratelimit actions attached to the route and scope it for responses (using the stage field) ?

so the problem for ai-gateway usecase with this getting use from header is; for streaming endpoints, the content is sent line by line and envoy shouldn't block the entire body but let it go through. OpenAI and AWS's streaming chat endpoint sends the usage stats at the very end of streaming, using a header as a communication medium is not suitable for that case. I think it's better to use dynamic_metadata as a communication between the producer (ai-gateway's case extproc which analyzes the streaming content) and the rate limit filter, and make the rate limit filter to subtract the usage from the budget on stream closure (not the header phase).

thanks for explaining that @mathetake , so we can use this GH issue to track 3 items

reusing ratelimit filter in response path in Envoy Proxy
supporting ratelimiting based on response In EG
exposing metadata as a first class selector (like header and client ip) in EG

sounds good - i will open an issue in envoyproxy/envoy to start the discussion with maintainers (i think wbpcode is owner of ratelimit)

so the Envoy side PR has landed the main - next is EG


⚠ Bofrost.de has degraded performance

In bc6ee03, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 949 ms

Resolved: Bofrost.de performance has improved in fc483e5 after 6 minutes.


Readme improvements

Update readme.

Codecov Report

Merging #40 (5a5bed1) into main (fa03f1e) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main      #40   +/-   ##
=======================================
  Coverage   73.28%   73.28%
=======================================
  Files           4        4
  Lines         307      307
=======================================
  Hits          225      225
  Misses         82       82

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@jrbourbeau do you have the chance to review / merge?

I agree, I was wondering why we named the package dask-deltatable and not dask-deltalake in the first place. To me dask-deltalake would be more telling, as well. I'll see if I can insert more of those keywords.

That name is already taken on PyPI. I reached out to the maintainer to see if we can have it. For now, we should stick with what we have.


Enable logging in next release of opentelemetry-cpp

Comment:
In the current release of opentelemetry-cpp (v1.2.0) there is an option to enable the experimental logging feature through the WITH_LOGS_PREVIEW CMake option. It's not enabled at the moment.
For users of the package, it looks like this functionality will only be exposed when using the ENABLE_LOGS_PREVIEW compile definition.
I'm not sure when this feature will leave its experimental status, and I'm not in a terrible hurry to use it. But, regardless of what it looks like in the next release, it would be nice if we could enable it, or whenever we have a reason to make a new Conda package build.
(If something I said here doesn't make sense, please correct me - I'm not very familiar with the Conda ecosystem yet.)

v1.3.0 just got released so I'll try to remember that. That said it seems metrics is getting more attention than logs at the moment.

Thanks for enabling the preview!


RainbowBraces stopped working after a VS crash

Hi
First of all, its a great extension. I was using it from version 1.0.78 and it worked fine.
But about 2 months ago (not sure but I think it was v1.0.105), Visual Studio 17.5.2 crashed and restarted. After the crash RainbowBraces stopped coloring braces. I have tried the following but to no avail:

Uninstalled and reinstalled the extension multiple times
Updated it regularly and now to the latest version 1.0.143
Updated Visual Studio to 17.6.2 and then to 17.6.4
Enabled and disabled VS inbuilt Enable brace pair colorization feature
Disabled and enabled all Braces and Brackets options in settings
Increased/decreased Cycle length option in settings
Changed Rainbow Brace Level # colors in settings
Cleared all caches

Any suggestions on what could be the issue and how to track and resolve it?

Hi,
that looks strange. Can you have a look at %appdata%\Microsoft\VisualStudio, there should be folder named 17.0_SOME_HASH (if there are more, the latest updated folder is likely the current Visual Studio) and in that folder there should be file named ActivityLog.xml. If there is anything related to RainbowBraces extension.
In 1.0.94 was implemented hack for Cascadia Code font. Are you using some unusual fonts? Or is missing Cascadia Code or Cascadia Mono from you computer?
When you try to install older version, is it working?
(eg. https://github.com/madskristensen/RainbowBraces/releases/download/1.0.92/RainbowBraces.vsix )

Oh, sorry I forgot to mention above that I had also checked ActivityLog.xml. There was/is no record of anything related to RainbowBraces in the log.
I'm using default font Consolas. I've just tried changing font to Cascadia Code and then Cascadia Mono but it doesn't change anything. Installing older version didn't work either.
I'd like to repeat that everything before the VS crash was working fine for a few months. Immediately after the restart of VS on crash, RainbowBraces stopped working. There was no change/upgrade of VS or any extension at that time.

Well, I have no idea what can be wrong. Maybe some corrupted file?
Can you try download this repo, open it in Visual Studio and attach to the another instance of Visual Studio (devenv.exe) and set function breakpoints to:
RainbowBraces.CreationListener.CreateTagger (is called when new window is opened)
RainbowBraces.RainbowTagger.ParseInternalAsync (is called every time a change occur and recalculate brace pairs)

And check if breakpoints are hit. If not, the extension is really somehow broken.
Also you can take a look if dll is loaded inside Visual Studio process with Modules window.

Hi
As guided I followed above steps with 1.0.147 and here are the observations:

RainbowBraces.dll is loaded inside Visual Studio process in Modules window
First breakpoint RainbowBraces.CreationListener.CreateTagger<T> is hit when a file is opened or scrolled down, but does not colorize any braces
Second breakpoint RainbowBraces.RainbowTagger.ParseInternalAsync is never hit even when editing/adding code in attached instance

I am not familiar with extension debugging/testing but do we also need to have the extension installed to debug its repo? RainbowBraces.dll loads in Modules window and CreateTagger breakpoint hits only when the extension is also installed.
It did not load in Modules and the breakpoint did not hit when I uninstalled the extension and debugged the repo.
There were no errors in Output and Error List windows while debugging.
There are no records in ActivityLog.xml

Ah, and I forgot. Have you checked this?


Fix inaccurate nodeos reference in wallet_api_plugin - 2.0

Change Description

Resolves #9090
Consensus Changes

[ ] Consensus Changes

API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Yes indeed they're different from nodeos plugins in that regard. We still need to document them since they're listed in the program help.


Luminous crafting table

I'm trying to get into Astral sorcery and need to make the luminous crafting table. You should be able to make it by linking a magical workbench to the collector crystal, but it does nothing. I tried crafting one in the workbench, nothing.  The jei says you need a crystal lense, but you need the starlight crafting table to make that. I'm stuck

I just tested and it works in singleplayer, It's just not working on my multiplayer server. I'm going to try a reboot and see if it works.

Reboot fixed it


Character limit for entity.id and productpurchaseid.

Issue in ./help/r-troubleshooting-target/target-limits.md
Hi Team,
In one of our recent implementation, we came across a situation where orderconfirmation mbox is failing due to long productpurchaseid length. Error message is "Errors: field - [execute.mboxes[0].order.purchasedProductIds] - purchasedProductId 'XXX' cannot exceed 50 characters;
Looking into this document on limitation, i could see that "entityID parameters" has character limit of 1000, i believe this is entity.id. But entityids in purchasedProductId comma separated can't be more than 47 characters. Which is contradictory? Can you please clarify on this?
Also, documentation says comma separated value exceeding 47 characters will be truncated but receiving error message as cannot exceed 50 characters.
Let me know if you have any questions.
Thanks,
Bala

Thanks for your input. I've worked with product management to update the following sections:

entity.id
productPurchasedId parameter

Does this clarify the limits adequately?


query result is converted to String instead of Date

activerecord <IP_ADDRESS>
activerecord-jdbc-adapter 1.3.25
activerecord-jdbcpostgresql-adapter 1.3.25
jdbc-postgres 9.4.1206
The following method call returns a Date when using ruby 2.3.3 but returns a String when using JRuby-<IP_ADDRESS> with activerecord-jdbcpostgresql-adapter:
2.3.3 :017 > Table.select('now() as date').first.date
  Table Load (0.7ms)  SELECT  now() as date FROM "tables"  ORDER BY "tables"."id" ASC LIMIT 1
 => 2019-05-17 03:46:52 UTC

jruby-<IP_ADDRESS> :002 > Table.select('now() as date').first.date
  Table Load (2.0ms)  SELECT  now() as date FROM "tables"  ORDER BY "tables"."id" ASC LIMIT 1
 => "2019-05-17 03:48:57.572526+00"

This only happens if the selected attribute does not exist in the database:
2.3.3 :012 > Table.select(:created_at).first.created_at
  Table Load (0.6ms)  SELECT  "tables"."created_at" FROM "tables"  ORDER BY "tables"."id" ASC LIMIT 1
 => Wed, 25 Sep 2013 14:26:17 -03 -03:00

jruby-<IP_ADDRESS> :019 > Table.select(:created_at).first.created_at
  Table Load (0.8ms)  SELECT  "tables"."created_at" FROM "tables"  ORDER BY "tables"."id" ASC LIMIT 1
 => Wed, 25 Sep 2013 14:26:17 -03 -03:00

This happens with either WebRick or Tomcat 7. This error does not occur with the same version of activerecord-jdbc-adapter if using Active Record 4.0 or 4.1. Upgrading to latest jruby-<IP_ADDRESS> did not help either.

https://stackoverflow.com/questions/56140906/query-result-is-converted-to-string-instead-of-date
As @kares noted, this look like a bug, also it is related to the configuration ActiveRecord::ConnectionAdapters::JdbcConnection.raw_date_time. Its seems like if it is set to true the method call below returns a String, otherwise it returns a Time instance:
Locatario.select('now() as date').first.date

I have checked this behaviour with 3 versions of active_record:
Rails 3.2
	default raw_date_time? == true
	Table.select('now() as date').first.date
		Ruby: returns String
		JRuby: returns String
Rails 4.0/4.1
	default raw_date_time? == nil
	Table.select('now() as date').first.date
		Ruby: returns Time
		JRuby: returns Time
Rails 4.2
	default raw_date_time? == true
	Table.select('now() as date').first.date
		Ruby: returns Time
		JRuby: returns String

So, it looks like to emulate active_record >= 4.0 the gem activerecord-jdbc-adapter should use raw_date_time = false, because it should return a Time instance with the method call in question. As a workaround I created a file with the following content under initializers:
if RUBY_PLATFORM == "java" && Rails::VERSION::STRING.starts_with?("4.2.")
	ActiveRecord::ConnectionAdapters::JdbcConnection.raw_date_time = false
end


Export int range is smaller than can be set in inspector

Godot version:

3.2.4-rc4
OS/device including version:

Windows 10
Issue description:

Attempted to set max value of exported int to (2^64)/2-1. It said it was too big. However, when setting the value of the exported int in the Inspector I can set it that high.
It appears that the exported int's range can only take numbers between -(2^32)/2 and (2^32)/2-1 while its actual value can be the values specified in the documentation.
Steps to reproduce:
Paste this line in some script:
export(int, -9223372036854775808,<PHONE_NUMBER>854775807) var number
Minimal reproduction project:

Duplicate of #33095


feature: Add @DgsDirective to simplify the directive declaration

I followed the steps of the discussion posts and tried to add a simple uppercase directive in my sample project, but it does not work as expected.
The uppercase directive wring class.
public class UppercaseDirectiveWiring implements SchemaDirectiveWiring {
    @Override
    public GraphQLFieldDefinition onField(SchemaDirectiveWiringEnvironment<GraphQLFieldDefinition> env) {

        var field = env.getElement();
        var parentType = env.getFieldsContainer();

        var originalDataFetcher = env.getCodeRegistry().getDataFetcher(parentType, field);
        var dataFetcher = DataFetcherFactories.wrapDataFetcher(originalDataFetcher,
                (dataFetchingEnvironment, value) -> {
                    if (value instanceof String s) {
                        return s.toUpperCase();
                    }
                    return value;
                }
        );

        env.getCodeRegistry().dataFetcher(parentType, field, dataFetcher);
        return field;
    }
}

And I created a bean @DgsRuntimeWiring in the data fetchers.  The complete codes is here: https://github.com/hantsy/spring-graphql-sample/blob/master/dgs-codegen/src/main/java/com/example/demo/gql/PostsDataFetcher.java#L24
@DgsComponent
public class PostsDataFetcher {

    @DgsRuntimeWiring
    RuntimeWiring.Builder runtimeWiring(RuntimeWiring.Builder builder) {
        return builder.directive("uppercase", new UppercaseDirectiveWiring());
    }

The partial content of the schema file:
directive @uppercase on FIELD_DEFINITION

scalar LocalDateTime
scalar UUID

type Post{
    id: ID!
    title: String! @uppercase
    content: String
    comments: [Comment]
    status: PostStatus
    createdAt: LocalDateTime
    authorId:String
    author:Author
}

When running the application, and test it on Graphiql, but it does not work. Not sure where is wrong.
This directive is working with my other Graphql example written in GraphQL Java and Spring Graphql.
Check: https://github.com/hantsy/spring-graphql-sample/tree/master/graphql-java/src/main/java/com/example/demo/gql/directives
Expected behavior
Similar to the existing @DgsScalar, I hope to add a @DgsDirective and apply it on the user's SchemaDirectiveWiring class directly to simplify the registration of a directive. eg.
@DgsDirective(name="uppercase")
public class UppercaseDirectiveWiring implements SchemaDirectiveWiring {}

Try to make your UppercaseDirectiveWiring a Spring Component by adding @Component and see if it works.

@ankit-joinwal  Check UppercaseDirectWiring and CustomRuntimeWiring, got the same result, no effect on response data.

@hantsy I checked out your project and found the problem in your setup.
If you make your runtimewiring method public its working (also you need to remove the second param of the method annotated with DgsRuntimeWiring.
Here the full code of CustomRuntimeWiring:
@DgsComponent
public class CustomRuntimeWiring {

    private final UppercaseDirectiveWiring uppercaseDirectiveWiring;

    public CustomRuntimeWiring(UppercaseDirectiveWiring uppercaseDirectiveWiring){
        this.uppercaseDirectiveWiring = uppercaseDirectiveWiring;
    }

    @DgsRuntimeWiring
    public RuntimeWiring.Builder customRuntimeWiring(RuntimeWiring.Builder builder) {
        return builder.directive("uppercase", uppercaseDirectiveWiring);
    }
}


"Package collision in lockfile" using UNC/root local device/etc paths

Problem
When invoking Cargo with the current directory or manifest path given as one of Windows' more "exotic" kinds of paths, such as a \\?\ "root local device path," internal path comparisons can fail and the build aborts. Ideally, Cargo would be able to handle these paths.
Steps
One way to reproduce the bug is with a directory structure like this:
bug/
  main/
    Cargo.toml
    src/lib.rs
  dep_a/
    Cargo.toml
    src/lib.rs
  dep_b/
    Cargo.toml
    src/lib.rs

main depends, via path = "../dep_a" and path = "../dep_b", on both dep_a and dep_b. dep_a also depends, via path = "../dep_b", on dep_b.
Here is a zip file containing the structure described above: path-bug.zip
Then, the bug can be triggered by running this command:
cargo build --manifest-path \\?\C:\full\path\to\bug\main\Cargo.toml

It produces an error message like this:
error: package collision in the lockfile: packages dep_b v0.1.0 (C:\full\path\to\bug\main\../dep_b) and dep_b v0.1.0 (C:\full\path\to\bug\dep_b) are different, but only one can be written to lockfile unambigiously

wasm-pack hits this issue because it sets the current directory to a canonicalized . when invoking Cargo. See https://github.com/rustwasm/wasm-pack/issues/380, https://github.com/rustwasm/wasm-pack/issues/413, and an attempt to work around this problem in https://github.com/rustwasm/wasm-pack/pull/389.
Notes
I most recently reproduced this with Cargo version cargo 1.31.0-nightly (5dbac9888 2018-10-08), on Windows 10.

It is a big laborious to recreate, isn't it? 😅
Here you go: path-bug.zip

No I am just feeling brain dead from Rust Belt Rust, and wanted a supportive response that did not involve me thinking for a while. Sorry.
Working from your zip I was able to reproduce locally. Oddly if the tomls are changed from / to \\ it works agen. So it is more like "Cargo does not normalize ../ when they are part of Windows' more 'exotic' kinds of paths."

So it is more like "Cargo does not normalize ../ when they are part of Windows' more 'exotic' kinds of paths."

Ah, this is very good to know. It gives us a good workaround for the wasm-pack scenario.

@alexcrichton So this looks like a path normalization bug, where do our source paths get normalized?

@Eh2406 I think it has to do with something around in src/cargo/util/toml/*, although I could be wrong!

It looks like this is where the path = "../dep" is handled: https://github.com/rust-lang/cargo/blob/master/src/cargo/util/toml/mod.rs#L1346-L1363
And this is the function it calls that's mostly likely to be giving bad results: https://github.com/rust-lang/cargo/blob/master/src/cargo/util/paths.rs#L47-L72

The most correct way to join ../foo onto an existing path on Windows is to interpret .. and . while appending. So if you started with \\?\C:\bar and joined ../foo you would iterate the components of ../foo and apply them to the base path, first applying .. to get \\?\C:\ and then applying foo to get \\?\C:\foo. Any method of joining paths that would result in \\?\C:\bar\../foo is wrong.

Hi guys, I've also encountered this issue while working with Trunk and Seed.
You can find the repo with a minimal example and some notes with a workaround here: https://github.com/MartinKavik/trunk-debug-deps


Ipwatch reporting false new ipaddress

After updating to Kubuntu 24.04 I experienced two new behaviour:
1/ the https://github.com/begleysm/ipwatch/issues/23 which I have rectified and
2/ the reporting of a changed IP address when in fact it has not changed
The error is only with the external IP address. In the latest instance the queried server was ipanywhere.com.
This occurs perhaps once a week while most of the time it works correctly.

Nr. 2 happens because some of the servers in serverCache.json don't exist/work anymore, and the file does not get updated regularly. I opted to disable the update mechanism in ipgetter.py and remove the invalid entries from the json myself.
I will be doing that regularly I think....

Thanks for that tip, I have edited my server list but have a question, a couple of sites have the check-human-user prompt. Do you know if this will stop IPwatch from working correctly? Also many results are in version 6 format but IPwatch only reports a version 4 number, are they converted?

IP Watch can't handle the IPv6-only page nor the "are-you-a-human" checks.
I'd welcome someone doing a once over on the server list (and adding more as appropriate).  I'll happily approve a PR with updates.

Thanks for that tip, I have edited my server list but have a question, a couple of sites have the check-human-user prompt. Do you know if this will stop IPwatch from working correctly? Also many results are in version 6 format but IPwatch only reports a version 4 number, are they converted?

I don't know, I started to modify this but soon realized it would be faster to start from scratch.... so that's what I did.
I re-made the tool with some different approaches on some things; seems to be working ok so far.

Here is a list of addresses that return an IPV4 result. The last 5 entries return both an IPV4 and IPV6 result but I do not know if Ipwatch can handle that? I have removed non viable addresses and added some new ones.
[     "http://checkip.dyndns.org/plain",     "https://canyouseeme.org/",     "https://www.ipchicken.com/",     "http://www.lawrencegoetz.com/programs/ipinfo/",     "http://ipgoat.com/",     "http://www.myipnumber.com/my-ip-address.asp",      "https://check.torproject.org/",     "https://www.geodatatool.com/",     "http://checkip.dyndns.com/",     "http://httpbin.org/ip",     "http://checkip.amazonaws.com",     "https://api.ipify.org",      "https://v4.ident.me",     "https://www.whatismypublicip.com",     "https://iplocation.com",     "https://www.showmyip.com",     "https://ip4.me",     "https://nordvpn.com/what-is-my-ip/",     "https://www.my-ip-address.co/",     "http://www.ip-adress.eu/",     "https://www.infosniper.net/",     "https://www.iplocation.net/find-ip-address",     "https://whatismyipaddress.com", ]


conflict in container name in otomi-core local debugging

Describe the bug:
When you open otomi-core in remote-container for debugging, you can not run otomi cli in your local machine anymore and you will get this error message:
docker: Error response from daemon: Conflict. The container name "/otomi-core-dev-container-1" is already in use by container "d3a6a2ecca6902241f5a9c082dff92144df1fe833fab19e13b94fb3a67d96925". You have to remove (or rename) that container to be able to reuse that name.

To Reproduce
open otomi-core in remote-container, then run otomi bootstrap command in your local computer.

I had to delete the container: otomi-core-dev-container-1 manually to be able to run otomi bootstrap in my computer

Maybe you had a run that got cancelled and resulted in container not being removed?
This is not happening to me at all (I think docker nicely removes containers with --rm), so I would like to ask you to ask others if they suffer from the same.
If this is about commands being run in the docker container, can you echo $IN_DOCKER there? That should be set as it is in the Dockerfile, but if it is not, something is wrong and it will try to run docker in docker, which is accommodated but not designed for the cli

I have not heard about this in a long time, so I deem this a non-issue. Closing


feat: How do I use custom labwear definitions I have created with the heater shaker module?

Overview
I can't seem to use custom labwear in the OT flex with the heater shaker module. How do I do it?
Sam
Implementation details
No response
Design
No response
Acceptance criteria
No response

Your custom labware definition needs to include a stackingOffsetWithLabware object that specifies the Heater-Shaker adapter you want to place the labware on, and the amount in mm that they overlap when stacked. See the labware schema explanation in the Flex Instruction Manual for more info.
Currently you need to add that object by manually modifying the labware definition JSON file. A future update to Labware Creator will also support adding and editing stacking offsets.


feat: implemented LRU caching for flagd provider

Closes #37
This PR implements standard caching functionality for the flagd provider. The configuration is done via the following env vars:
| Caching                      | FLAGD_CACHE                    | string  |           |     LRU       |
| Maximum cache size           | FLAGD_MAX_CACHE_SIZE           | number  | 10        |               |
| Maximum event stream retries | FLAGD_MAX_EVENT_STREAM_RETRIES | number  | 3         |               |

When caching is enabled, the flagd provider will establish an EventStream with the flagd server via grpc, and listen for configuration_change events. When such an event is received for a flag that has already been cached previously, that flag will be removed from the cache. When retrieving the value of a feature flag, the value will be cached if the Reason of the resolution is set to STATIC.
Note: The imported version of the OF dotnet-sdk is set to 0.5 - Since this version does not yet include the configuration_change event type, or the STATIC reason type for the resolutionDetails, it might be worth to consider bumping the version of the imported dotnet-sdk as a follow up task.
Note: Since the Event Stream is opened in a background task, I was not quite sure how to best verify in the Unit tests that things like the removal of a cached item were properly called by the provider. Coming from Golang, I was missing something like require.Eventually(t, len(mockCache.DeleteCalls) == 1).  I tried to resemble that behaviour by creating an AutoResetEvent that gets set in the mock implementation of the method I would like to ensure it was called. Then, using Assert.True(_autoResetEvent.WaitOne()) I waited for the event to be triggered. This solution does seem to work, but if there is a better approach to this in C# I appreciate every input from the reviewers of this PR

Note: Since the Event Stream is opened in a background task, I was not quite sure how to best verify in the Unit tests that things like the removal of a cached item were properly called by the provider. Coming from Golang, I was missing something like require.Eventually(t, len(mockCache.DeleteCalls) == 1). I tried to resemble that behaviour by creating an AutoResetEvent that gets set in the mock implementation of the method I would like to ensure it was called. Then, using Assert.True(_autoResetEvent.WaitOne()) I waited for the event to be triggered. This solution does seem to work, but if there is a better approach to this in C# I appreciate every input from the reviewers of this PR

I think your testing strategy is fine. I find the tests around caching about as readable as possible given the complexity. They look similar to the ones in other contribs.
I think my only request with them is that you add timeouts to every WaitOne() to prevent the tests from hanging forever in cases where they break because the awaited function is not called. I purposely broke some tests locally and it seems like Xunit happily runs until I manually kill the process :joy:

Hey @bacherfl , IMO this all looks really great. I love your cache impl. I've left mostly optional/suggested changes except this one, which seems pretty small but will prevent CI/tests from hanging if people break something when making changes.

Thanks @toddbaert for your review and suggestions - I agree with all of them, and will try to include them into this PR

alright, I have submitted all changes/suggestions, so the PR should be ready for another review :)


Cant get Humble to work

Hello,
I cannot get the examples in the Humble branch to work with Fortress.
The Dockerfile does not build:
14.67 /home/ros2_ws/src/gz_ros2_control/gz_ros2_control/src/gz_ros2_control_plugin.cpp: In member function ‘virtual void gz_ros2_control::GazeboSimROS2ControlPlugin::Configure(const Entity&, const std::shared_ptr<const sdf::v12::Element>&, ignition::gazebo::v6::EntityComponentManager&, ignition::gazebo::v6::EventManager&)’:                                                                    14.67 /home/ros2_ws/src/gz_ros2_control/gz_ros2_control/src/gz_ros2_control_plugin.cpp:424:67: error: ‘__gnu_cxx::__alloc_traits<std::allocator<hardware_interface::HardwareInfo>, hardware_interface::HardwareInfo>::value_type’ {aka ‘struct hardware_interface::HardwareInfo’} has no member named ‘hardware_plugin_name’                                                                             14.67   424 |     std::string robot_hw_sim_type_str_ = control_hardware_info[i].hardware_plugin_name; 14.67       |                                                                   ^~~~~~~~~~~~~~~~~~~~
I suspect that's because the Dockerfile does not check out the humble branch.
When trying to launch the examples without docker, I just get an empty gazebo and the error message:
[ros2-4] Could not contact service /controller_manager/load_controller [ERROR] [ros2-4]: process has died [pid 45464, exit code 1, cmd 'ros2 control load_controller --set-state active joint_state_broadcaster']. [INFO] [ros2-5]: process started with pid [45706]
I tried building the examples against the binary installation of ign_ros2_control and against source, same result.
Am I doing something wrong?
EDIT:
When adding the controller manager to the launch file like this:
    control_node = Node(         package="controller_manager",         executable="ros2_control_node",         parameters=[controller_file],         output="both",         remappings=[             ("~/robot_description", "/robot_description"),         ],     )
I get all the vehicles that were previously missing at one, which is also weird?

I have no idea what fixed it but after the 3rd reboot it now works. Please close.

I have no idea what fixed it but after the 3rd reboot it now works. Please close.


Refine the .circleci/config.yml by using dynamic config

Currently, we have these hard coded and repeated sections in the .circleci/config.yml for testing each go.mod.
https://github.com/redis/rueidis/blob/16d5f135a57f14205bab0850108c86e10913f56c/.circleci/config.yml#L14-L35
It will be better if we can detect every go.mod files automatically and generate .circleci/config.yml dynamically through the
https://circleci.com/docs/dynamic-config/.

Here is an example of how we can detect every go.mod files:
https://github.com/redis/rueidis/blob/16d5f135a57f14205bab0850108c86e10913f56c/.github/workflows/tag-subpkg.yml#L26-L28

Thank you @moonorange!


Add additional keys to release key fingerprints [1.1.1]

Added keys for Paul Dale and Tomáš Mráz.
Checklist

[x] documentation is added or updated

ping for the reviews

Agree urgent. Should be in the release today.
Ping for a second review

@paulidale @levitte could you please approve?

Updated key for @paulidale included.

@mattcaswell please re-approve. Also @paulidale do you agree with urgent? We want to add it to the release.

Yes, urgent.

Repo is currently frozen so it won't appear there yet - but this will be included in today's release.


[Issue] Access Token Not Refreshing

App fails to refresh the API user token if it has been open for longer than one hour. At the moment the app requires a restart for the token to be refreshed. This needs to be fixed.
The function to refresh tokens can be found inside of app.py on the master branch.

I get the same problem. The console yields the following lines:
[WARNING] Could not refresh user API token
HTTP Error for GET to https://api.spotify.com/v1/me/player returned 401 due to The access token expired

This has been fixed


stage1: shutdown.service: don't use /dev/console

The default stdout for shutdown.service is /dev/console (the tty created
by nspawn). But that tty might be destroyed if rkt is executed via ssh
and the user terminates the ssh session. We still want shutdown.service
to succeed in that case, so don't use /dev/console.
Fixes https://github.com/coreos/rkt/issues/2232

@lucab PTAL

Nice work!
This LGTM but I'll wait for @lucab

Thanks for connecting the final dots, I missed the cgroup hints towards the reaper.
LGTM too, we'll merge it tomorrow post-release.

great find!


option to show other markers

Hi, a option to show other markers / or all on the detailpage would be nice.. or maybe only nearby..
thanks
Denis

Hi @Dontorpedo thanks for submitting that idea. However, for now I think I will leave that feature out, because it doesn't really match with the intended purpose of this package. Could you expand on why this feature is important to your use-case?

Hi, yes!
it would be very helpfull for winter service tour planning, and services that are charged depending how many customers are nearby

@Dontorpedo Thanks for following up. For that to be programmatically useful though, I would think you would need to have more information returned than just the coordinates of the marker. For example, you would need the coordinates of the nearby markers, perhaps with distance and direction from the original marker, to be able to use it in any significant way.
This field is intended solely for determining lat/long coordinates of a given point on the map.
For more complex things, it is probably better to create your own custom field with the specific functionality you need, or perhaps even not do it in Nova, but have it be first-citizen functionality of your app.
I'm only guessing, of course, based on your short description -- it's difficult for me to envision exactly what your intentions are.

I can see what you mean by showing other markers nearby on the detail screen to give context, though.
If we limited it to nearby markers, we would have to have GIS functionality in the database to calculate distance in the where clauses. If we loaded all markers, it could quickly crash the page.
I'm going to put this on hold for now, but keep it here in case I can think of a good way to implement it. I'll be happy to consider a PR if you want to submit one and it is performant :).


Properly validate PUT requests

As it stands, the request body of PUT requests is simply ignored.
This stems from the reliance on the Symfony ServerRequestInterface/getParsedBody() function, which, in case of a PUT request, will simply ignore the body. Of course, that's the intended behavior of that function, but that is not the behavior expected in the context of this validator, and in fact, can create a very serious security risk due to being relatively easy to miss.
As such, I offer a hotfix, in the form of the added function parse_raw_http_request() (taken from stackoverflow, all credit to the author, thread is linked), which parses body parameters in case of a PUT request, and using it in that case.
This is just a hotfix, as the author of that function warned it might not cover some edge cases, but in my opinion it's better than having no validation of PUT body parameters at all.

All tests are obviously failing, since this behaviour is not really testable and explicitly operates global state which is bad practice.
Also no new tests provided, which should describe given problem.

This is one of those commits after a sleepless night, pretty busy right now, but give me a few days and I'll see how I can properly implement this.

I hope the proper way to fix this is to bring this logic into PSR-7 implementation libraries, not to the PSR-7 user libraries. Because this may lead to the problem that the PUT request content is not used in the same way as it was validated, so this will lead to errors and custom hack in this code. We should rely on standard approaches here, not the custom code.

This code make way to many assumptions about the environment it's running in
It assumes:

the request body is in php://input that's not true if you do async development or use bref without php-fpm
that all PUT request most be multipart/form-data witch is definitely not true
$_SERVER is populated for most of my application it's not
it ignores getParsedBody() for PUT request even thru it might not be empty

Sorry for being a bit harsh but this is just the wrong way to solve the problem your having
Now have you had a look at something like https://github.com/Kekos/parse-request-body-middleware that you could invoke before using the validator and it would handle the parsing for you?

Thanks @sunkan for deep explanation! Fixing all these points will lead to fixing request object (with middleware) or request factory instead, so I think dealing with this problem is out of scope of this library


Moved automatic/ into pagespeed/ and got rid of the public/ hierarchy.

The svn changes for this are already submitted (my mistake) so ngx_pagespeed won't build without this patch applied.

LGTM