pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[elorimer]

Hmm. I'm getting a message that pixelserv failed to start, but it is clearly working:

Sep 16 07:15:27 pixelserv[29810]: /jffs/bin/pixelserv-tls version: v35.HZ12.Ki compiled: Sep 15 2016 23:02:57 options: 192.168.0.3
Sep 16 07:15:27 pixelserv[29810]: Listening on :192.168.0.3:80
Sep 16 07:15:27 pixelserv[29810]: Listening on :192.168.0.3:443
Sep 16 07:15:38 elorimer: Failed to start /jffs/bin/pixelserv-tls from .
Sep 16 07:17:25 pixelserv[29810]: Failed to create conn_handler thread

 

[kvic]

pixelserv-tls is a little multi-thread daemon. Inside its main thread, it listens for client connections. When there is one it creates a new thread to handle the connection from this client, process its request and send back response. The new thread shuts down when done with that particular request.

Sep 16 07:17:25 pixelserv[29810]: Failed to create conn_handler thread

The above error prints to syslog when pixelserv-tls cannot create such a thread. The error is most likely transient. Only to do with a particular request. Occasionally you will see it when your router is short of resources such as RAM. If you're seeing this error more frequently, it's a good indication your router might be working too hard.

 

[kvic]

Sep 16 07:15:38 elorimer: Failed to start /jffs/bin/pixelserv-tls from .

This error mostly likely a false alarm if pixelserv runs actually. Entware's init.d scripts maybe don't like full pathname in PROCS variable.

In case, it really bothers you. Prepend "/jffs/bin" to PATH a few lines above, then you can simply put PROCS="pixelserv-tls". Remember to revert the PATH change when you update to Entware's version though.

 

[elorimer]

This error mostly likely a false alarm if pixelserv runs actually. Entware's init.d scripts maybe don't like full pathname in PROCS variable.

In case, it really bothers you. Prepend "/jffs/bin" to PATH a few lines above, then you can simply put PROCS="pixelserv-tls". Remember to revert the PATH change when you update to Entware's version though.

That worked.

 

[Popov]

@kvic
Could you comment in Makefile, the line #100 running the $(UPX) command in the x86 build ?
It's one of the last still present, and not much usefull for this architecture

This minor detail aside, Ki is working fine, thanks

 

[kvic]

@kvic
Could you comment in Makefile, the line #100 running the $(UPX) command in the x86 build ?
It's one of the last still present, and not much usefull for this architecture

This minor detail aside, Ki is working fine, thanks

Thanks for the feedback. Done!

UPX has no benefit for mips/arm/amd64..and i386. I removed the line for these platforms.

 

[elorimer]

Not sure what might be going on, but my pixelserv-tls (.ki, static build) stops running after a few hours. This is on an 87u with .62.

The not-found boxes reappear, nothing in top, and no response on the stats page. It restarts without a problem and then is fine. Nothing in the syslog between starting and no longer running, except an attached drive spinning up and down. Not a lot to go on, so I'll keep watching.

Edit: This last go round .ki only worked for around 10 minutes. I've gone back to .kh.

 

[mstombs]

...
UPX has no benefit for mips/arm/amd64..and i386. I removed the line for these platforms.

The original (buggy, much fewer features) C pixelserv version had a dynamic binary only 4kB big that could be uuencoded into nvram. I recall upx helped keep the binary down to 20kB which was useful for some jffs users. With usb disks I agree no benefit, and probably uses more ram/ ram defragmentation for the decompressor, so no-upx is more efficient.

 

[kvic]

Not sure what might be going on, but my pixelserv-tls (.ki, static build) stops running after a few hours. This is on an 87u with .62.

The not-found boxes reappear, nothing in top, and no response on the stats page. It restarts without a problem and then is fine. Nothing in the syslog between starting and no longer running, except an attached drive spinning up and down. Not a lot to go on, so I'll keep watching.

Edit: This last go round .ki only worked for around 10 minutes. I've gone back to .kh.

Thanks for letting me know. Seems to me your pixelserv crashed. I had been very careful in making changes from fork() to pthread in Ki but I won't be surprised if there are bugs there. My latest run is over 1 day and counting. Last run was more than a few days I think. But I've been rebooting my Asus for other business. So can't have a long run recently. Will watch out if I could reproduce the issue and fix it.

Go back to Kh is a wise move if you want stability. I had a good run for many months on Kh.

 

[thelonelycoder]

@kvic would you consider to add a path to a file for -l option?

 

[kvic]

@kvic would you consider to add a path to a file for -l option?

Hi, at the moment, I want to settle the "stability issue" reported on Ki first before making any further changes..

Personally I also don't see a use case for logging to a separate file. When I expanded the logging feature last year, I already thought about if I shall only log to syslog or provide a second mean to write to a file. I sticked to only syslog.

My reasoning was that for occasional analysis of what sites to whitelist, turn on/off the logging on the fly and grep the syslog getting the task done fairly quick.

For 24-7 logging lunatic (like myself), writing to syslog is also the preferred choice for performance. Writing to disk slows down pixelserv. For these lunatics, they probably shall know it's the syslog on AsusWRT that need an upgrade

 

[swetoast]

why log to a separate file ? what would be the benefit ?

 

[thelonelycoder]

For 24-7 logging lunatic (like myself), writing to syslog is also the preferred choice for performance. Writing to disk slows down pixelserv. For these lunatics, they probably shall know it's the syslog on AsusWRT that need an upgrade

why log to a separate file ? what would be the benefit ?

More a notion I had than a real need. Don't bother implementing it.
Since syslog can be delayed writing to file, I had the idea of briefly using a log facility to check certificate creation.
The next version of AB-Solution features an automated install of pixelserv-tls and I check every step of it to make sure it'll work.
I found a reliable way of doing it on the fly.

 

[kvic]

More a notion I had than a real need. Don't bother implementing it.
Since syslog can be delayed writing to file, I had the idea of briefly using a log facility to check certificate creation.
The next version of AB-Solution features an automated install of pixelserv-tls and I check every step of it to make sure it'll work.
I found a reliable way of doing it on the fly.

If this could be of help, you can temporarily run pixelserv without entering daemon mode i.e force it foreground with option -f. Output and error will be sent to stdout/stderr. From there you could pipe it to a file you pick..

Great to hear pixelserv-tls getting integrated again

 

[thelonelycoder]

If this could be of help, you can temporarily run pixelserv without entering daemon mode i.e force it foreground with option -f. Output and error will be sent to stdout/stderr. From there you could pipe it to a file you pick..

Great to hear pixelserv-tls getting integrated again

Thanks, that may he the better option. I'll look into it.
As with all the other features in AB-Solution, you can turn on and off pixelserv. ATM I stop ps and remove the S80 file so it will not start if you happen to reboot the router. This is probably the only way to do it right, is it?

 

[kvic]

Thanks, that may he the better option. I'll look into it.
As with all the other features in AB-Solution, you can turn on and off pixelserv. ATM I stop ps and remove the S80 file so it will not start if you happen to reboot the router. This is probably the only way to do it right, is it?

There is a built-in feature in Entware's init scripts, ENABLE=. A better way will be: "/opt/etc/init.d/S80<xxx> stop" to kill pixelserv-tls and then toggle ENABLE in S80<xxx>. ENABLE=yes will run on startup. ENABLE=no won't.

 

[thelonelycoder]

There is a built-in feature in Entware's init scripts, ENABLE=. A better way will be: "/opt/etc/init.d/S80<xxx> stop" to kill pixelserv-tls and then toggle ENABLE in S80<xxx>. ENABLE=yes will run on startup. ENABLE=no won't.

Perfect, I forgot about that. Now I remember.
One other thing, before I go away for the rest of the WE, is there a way to save the ps generated stats to have ps pick up where it left?

 

[kvic]

Perfect, I forgot about that. Now I remember.
One other thing, before I go away for the rest of the WE, is there a way to save the ps generated stats to have ps pick up where it left?

Unfortunately not now.

Pixelserv has both text (passable) and html stats. The text stats could be made of good use here. When pixelserv quits, it'll log the text stats to syslog like this:

Sep 27 02:16:12 Phaeo pixelserv[828]: 1424 uts, 1 log, 10 req, 522 avg, 1350 rmx, 84 tav, 233 tmx, 7 slh, 0 slm, 0 sle, 0 slu, 2 nfe, 0 gif, 0 ico, 5 txt, 0 jpg, 0 png, 0 swf, 0 sta, 0 stt, 2 ufe, 0 rdr, 0 nou, 0 pth, 0 204, 1 pst, 0 hed, 0 bad, 0 err, 0 tmo, 0 cls

These are parsable by standard unix utilities such as AWK.

If you like to do an accumulated stats, say, since initial install, you could regularly take a snapshot of this text stats. The weekly update of host file timeframe could be a good place.

Store such stats in text files. Mark last startup time of pixelserv. Then you shall be able to calculate accumulated stats since initial install. Present the data in a new menu item...with designer's pick of color and layout...

It could be a cool and unique feature of ab-solution *grin*

 

[mstombs]

Unfortunately not now.

Pixelserv has both text (passable) and html stats. The text stats could be made of good use here. When pixelserv quits, it'll log the text stats to syslog like this:

Sep 27 02:16:12 Phaeo pixelserv[828]: 1424 uts, 1 log, 10 req, 522 avg, 1350 rmx, 84 tav, 233 tmx, 7 slh, 0 slm, 0 sle, 0 slu, 2 nfe, 0 gif, 0 ico, 5 txt, 0 jpg, 0 png, 0 swf, 0 sta, 0 stt, 2 ufe, 0 rdr, 0 nou, 0 pth, 0 204, 1 pst, 0 hed, 0 bad, 0 err, 0 tmo, 0 cls

...

You can get the stats into syslog without quiting pixelserv by signalling it with sigusr1, in my case

admin@RT-N66U:/tmp/home/root# killall -USR1 pixelserv-tls

Results in addition to log (and I store logs on another machine hard disk using remote syslog function!)

Oct  1 09:52:31 pixelserv[606]: 2191102 uts, 351332 req, 1562 avg, 56527 rmx, 131 tav, 3972 tmx, 0 err, 3865 tmo, 332752 cls, 0 nou, 0 pth, 4245 nfe, 388 ufe, 180 gif, 3 bad, 4602 txt, 3 jpg, 18 png, 3 swf, 3 ico, 331434 slh, 14 slm, 0 sle, 577 slu, 1 sta, 0 stt, 0 204, 4991 rdr, 269 pst, 0 hed, 0 log

 

[thelonelycoder]

@kvic: Entware now installs:
pixelserv-tls version: v35.HZ12.Ki compiled: Oct 30 2016

Thank you!
I have not seen any announcement here or whether you were aware of the fact.
Just checked it and tested it with the soon to be released AB-Solution 3.
Seems to work without a problem, the same switches are still in use and appear to work with my scripts.

I like the redesigned html stats, they are a lot better to read now, especially with the description.
Very well done.

And Ki comes just in time for the users of AB-Solution 3 to profit as well.

Edit: Apparently only MIPS routers get the new Ki version.