Modify

Opened 4 years ago

Last modified 4 years ago

#16863 new defect

udpxy is flooting /tmp/log

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: packages Version: Trunk
Keywords: Cc:

Description

Dont know since when this happens, but udpxy is flooting the logs with nonsense entries. Was wondering why my ram is full and noticed it was because of udpxy log file being 60mb big. Did you guys change something in init.d file for udpxy?

config udpxy

option verbose '0'
option status '1'
option bind '0.0.0.0'
option port '4022'
option source '0.0.0.0'
option max_clients '3'
option log_file '/var/log/udpxy'
option buffer_size '2048'
option buffer_messages '1'
option buffer_time '1'
option nice_increment '0'
option mcsub_renew '0'

Shouldnt verbose 0 do something about it? Mostly being ignored.

Log fie is spammed with things like this:

2014-06-21 21:26:55.518292 CEST c(16092) received new [1364] bytes out of [2048], last=[576]
2014-06-21 21:26:55.518845 CEST c(16092) sent [1316] bytes out of [1364], last=[564]
2014-06-21 21:26:55.519104 CEST c(16092) received new [1328] bytes out of [2048], last=[1364]
2014-06-21 21:26:56.602048 CEST c(16092) received new [1140] bytes out of [2048], last=[1328]
2014-06-21 21:26:56.602324 CEST c(16092) sent [1128] bytes out of [1140], last=[1316]
2014-06-21 21:26:56.602531 CEST c(16092) received new [1364] bytes out of [2048], last=[1140]

r41181

Attachments (0)

Change History (6)

comment:1 Changed 4 years ago by anonymous

Tried status '0', didnt change anything. Log still gets flooded with these messages if a client is connected:

2014-06-22 20:28:22.169111 CEST c(2327) received new [1364] bytes out of [2048], last=[764]
2014-06-22 20:28:22.169503 CEST c(2327) sent [1316] bytes out of [1364], last=[752]
2014-06-22 20:28:22.172099 CEST c(2327) received new [1328] bytes out of [2048], last=[1364]

Starting argument is:
2014-06-22 20:25:07.593467 CEST S(1241) udpxy 1.0-23.9 (prod) standard [Linux 3.10.36 mips]: /usr/bin/udpxy -T -a 0.0.0.0 -p 4022 -m 0.0.0.0 -c 3 -l /var/log/udpxy -R 1 -H 1 -M 0

comment:2 Changed 4 years ago by anonymous

For now I have disabled log in /etc/init.d/udpxy:

#procd_append_param command -l $cfg_log_file

Please look into this, why it's spamming the log with this debug output. Even if it's disabled, it still spams the log to stderr which shouldnt be the case.

comment:3 follow-up: Changed 4 years ago by noltari@…

Thanks for reporting.
Should be fixed now: https://github.com/openwrt/packages/commit/bcd2e39bfa498c931aa06c5e1e3b1f10367a6216

Regards,
Álvaro.

comment:4 in reply to: ↑ 3 Changed 4 years ago by anonymous

Replying to noltari@…:

Thanks for reporting.
Should be fixed now: https://github.com/openwrt/packages/commit/bcd2e39bfa498c931aa06c5e1e3b1f10367a6216

Regards,
Álvaro.

Hi there! Thanks for looking into this. But why did you out comment most all settings in the default config file? So I guess this sets all settings to "" which are default settings, meaning no log file at all, isnt there an option with log file but no debug outputs?

comment:5 follow-up: Changed 4 years ago by noltari@…

I checked udpxy code and passing a log file enables all these flooding logs no matter what verbose setting is or not enabled.

So, in order to fix this and have a log file with reasonable logs, udpxy would need to be significantly modified.

I commented out most settings in order to use the default values, like it was before udpxy config was introduced.

Regards,
Álvaro.

comment:6 in reply to: ↑ 5 Changed 4 years ago by anonymous

Replying to noltari@…:

I checked udpxy code and passing a log file enables all these flooding logs no matter what verbose setting is or not enabled.

So, in order to fix this and have a log file with reasonable logs, udpxy would need to be significantly modified.

I commented out most settings in order to use the default values, like it was before udpxy config was introduced.

Regards,
Álvaro.

That was what I thought, because you guys changed the init.d script some weeks ago I think, and before that, it had just one simple start argument without any options at all, therefor no log, and therefor no one noticed it writing the ram/log full.

Another thing Ive noticed which is "new", udpxy process is now 3-4 processes (before it was always just one) and in sum it takes way more cpu than back before (now around 20%, before ~6%). It's also weird because the amount of processes seem to switch. If it's started: 1, when you open a stream: 3, when you switch channel: 4, after a random time it's back to 3, than suddenly 2.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.