Information, Support and FAQ forums for OutagesIOOur FREE software monitors your Internet service and provider then alerts you when you have connection issues or downtime. For home, small business, IT companies and enterprise. Monitor Internet outages, track network connection reliability, and get proof you can use. For Windows 7, 8, 10, Centos 7, 8, Debian 7, Ubuntu, ARM (Raspberry, Tinker Board, etc).
Learn more about www.outagesio.com by visiting our web siteNOTICE: If you previously registered on forums.outages.io, simply use the 'Forgot Password' option to recover your account.
outages.io in a docker container
I want to run outages.io in a container and then add it to the Unraid appstore.
I have done this using Debian but it's quite large, also the agent isn't connecting. I'll post about that after I've done some more troubleshooting. Links below for reference.
Ultimately I'd like to run this on Alpine Linux so it ends up small, but I get the following issue that prevents me from running the binary, any idea what this issue is?
/otm # ldd otm_linux
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f360a322000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f360a181000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f360a322000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f360a167000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f360a322000)
Error relocating otm_linux: __res_init: symbol not found
Hi, running the same against our Linux version on Centos 8, I get the following.
# ldd otm_1.67.2104_linux linux-vdso.so.1 (0x00007ffe0fb6b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f47a4aa0000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f47a470b000) libm.so.6 => /lib64/libm.so.6 (0x00007f47a4389000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f47a4171000) libc.so.6 => /lib64/libc.so.6 (0x00007f47a3dac000) /lib64/ld-linux-x86-64.so.2 (0x00007f47a4cc0000)
I suspect it is because our Linux version was built on Centos 7.6.1810.
On our Aarch64 version;
# ldd otm_aarch64 linux-vdso.so.1 (0x0000007faf011000) libpthread.so.0 => /usr/lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007faef73000) libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007faed8e000) libm.so.6 => /usr/lib/aarch64-linux-gnu/libm.so.6 (0x0000007faece1000) libgcc_s.so.1 => /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007faecbd000) libc.so.6 => /usr/lib/aarch64-linux-gnu/libc.so.6 (0x0000007faeb4a000) /lib/ld-linux-aarch64.so.1 (0x0000007faefe1000)
Unfortunately, our dev that works on the agents has been sick for a while, we are unable to provide much more information right now.
I don'k know if there is a work around for something like this.
On the other issue, can you start a new post when you're ready with that test and we'll certainly try to help.
Have you had any luck with this?
Were you able to solve the other problem that you mentioned for another post?
I didn't change anything my end, reinstalled my container (which pulls down the latest agent) and I think it's connected now. I'm not able to see any stats though because seems you charge for this now. How do I verify it's connected?
@peachy Let's see what's happening. Can you share the agent ID please.
@outagesio_support sure, 128433
Yes, there is a small subscription fee for Extended reports. Development hours on this project are insane and costly.
I've upgraded that agent to help in your development effort so please don't delete that agent :).
You'll see it's sending pings and if you enable speed testing, you should see that too. Once you have outages, you'll see those.
Can you expand on how to fixed the problem 'linux-vdso.so.1'.
I haven't fixed it, the Debian based container works now so I guess you updated the agent in the last few weeks. The issue you refer to occurs in the alpine Linux container, I could take a look at that later.
So I think the docker image I provided works so you can probably run that at your end and test it. I also provided a template to run this in unraid which should work on unraid too.
I do think that the data provided without subscription isn't enough for people to feel it worth to run the container I created, personally if I couldn't verify it was running I'd just delete it. Happy to discuss this further of you want to.
We've tried a number of different ways to have a free version and earn enough to keep the service going.
We are always open to ideas but developers and resources aren't free, all of it is expensive and incredibly time consuming so we need to bring in some income.
We do keep it inexpensive as possible and the free version seems to work for most people which is how we came up with the pricing.
Always open to ideas of course.
@outagesio_support I guess I'd look at it the other way and think of who would pay for the paid version then try to increase userbase on the free. Users like myself would never pay the fee for premium not because I think the service isn't worth it (i'm here discussing with you after all) but because for $70 a year i could get a small vm for the same sort of money I could also do other stuff with.
The data produced has value too because if it gained enough support it could hold ISPs to account, which is what attracted me to what you guys were doing in the first place.
Where are the costs? My guess
- Development which you have to do anyway
- Hosting the service (graphs, analytics)
- Hosting the endpoint
- Building support for the agents on different platforms.
The last two you could get community support with, the first two if you wanted community support you'd have to open source your software which you likely don't want to do or you would have done it already. Maybe if the agent wrote metrics locally in a logfile or something that could be included in free?