Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

The Eternal Väinämöinen -- Seedboxes Starting From 1.99€/Month or 6.99€/Year -- 700 Years Give Away

11213151718

Comments

  • SNATCHED ONE ETERNAL, ORDER ID: 4211449594

    Thanked by 1PulsedMedia
  • SNATCHED ONE ETERNAL, ORDER ID: 6738507584

    Thanked by 1PulsedMedia
  • PulsedMediaPulsedMedia Member, Patron Provider

    @stupidgenius said:
    @Killix and @JohnnySac
    You might be able to open a ticket and ask for the PMSS update and reconfig, also ask Vain-man to double check the cgroup V1 limits and the over all node load.

    If it is really bad, you might try asking to be moved to a different node, however NOTE they will NOT migrate your data for you, it will be a clean node. So make sure you have the data stored elsewhere before requesting and confirming that.

    @PulsedMedia said: @stupidgenius open a ticket, request pmss update + reconfig. Those IOPS numbers look too low and identical accross, we have seen this bug before -> All capped to 100 IOPS exactly. It was a bug. Which lead to discovery that certain Cgroup V1 limits work which should not have worked according to prior information.

    This is correct, there was some misconfigs etc. and the patches are still propagating, we do rolling release. opnly some are affected.

    @fuzhyperblue said:
    I want to document my experience with "Väinämöinen" AI support of Pulsed Media:

    I started receiving persistent “503 Service Unavailable” errors on 17 August 2026. The web UI remained unusable for approximately seven days.

    Timeline:

    17 August:
    I reported that I was receiving 503 errors on my seedbox every other day.

    18 August:
    AI agent initially said the problem was caused by heavy disk activity on the shared server. They (it?) said my account, torrents, and data were healthy, and that the panel should recover when the server load decreased.

    19–24 August:
    The panel continued returning 503 errors. I repeatedly explained that this was not an occasional problem anymore: the web UI had been unavailable continuously for days. I also asked whether I could be moved to a less crowded server.

    AI agent continued to attribute the problem to shared-server disk I/O and suggested using SSH and the rTorrent console as a workaround. They also stated that a server move could only be done through a new order.

    25 August:
    AI agent again claimed that the panel was responding at the moment they checked it and described the issue as a load-related condition that came and went. I disagreed because the authenticated web UI had not been usable for almost a week.

    My own investigation:
    I connected through SSH and found that:

    • The rTorrent process was running normally.
    • The rTorrent SCGI socket was active at /home/myusername/.rtorrent.socket.
    • The existing ruTorrent installation was present at /home/myusername/www/rutorrent.
    • ruTorrent was correctly configured to use the rTorrent socket.
    • No changes were made to my torrents or rTorrent configuration.

    I then started a temporary PHP web server on the seedbox and accessed it through an SSH tunnel. The ruTorrent interface worked correctly through this tunnel. This demonstrated that rTorrent, ruTorrent, my account, and my data were healthy. The problem was in the normal web-serving layer.

    28 August:
    After further escalation and pushing the AI agent, it finally identified and acknowledged the actual problem:

    • lighttpd was running;
    • however, the PHP-CGI backend processes had crashed;
    • the PHP-CGI workers were stuck in a failed-restart loop;
    • authenticated panel requests therefore returned 503 continuously.

    AI agent also explained that unauthenticated requests could show the login page without reaching the failed PHP backend. This caused their earlier external checks to appear successful even though the logged-in panel was broken.

    AI agent restarted the PHP-CGI backend, reported that seven workers were running normally again, and the web UI became available.

    Conclusion:

    The original diagnosis of a continuously failing panel due only to disk I/O was incorrect. Server load may have contributed to the PHP-CGI failure, but it was not the direct reason the authenticated web UI remained unavailable for seven days.

    The actual fix was AI agent restarting the failed PHP-CGI backend.

    Happy Ending: I was also given one additional week of service time in recognition of the outage. This also was AI agent's decision.

    The Good Side and The Bad Side both, from a technological point of view: nobody at Pulsed Media is aware of the problem, it is solved entirely by AI agent. If a human was responding, it could be solved quicker. But it got solved, with no human time spent by Pulsed Media staff.

    We constantly work on the documentation etc. next time it will be easier for väinämöinen.

    Thanks for being so thorough. Remeber to do the eternal story thing for credit!

    @stupidgenius said:

    @fuzhyperblue said: The Good Side and The Bad Side both, from a technological point of view: nobody at Pulsed Media is aware of the problem, it is solved entirely by AI agent. If a human was responding, it could be solved quicker. But it got solved, with no human time spent by Pulsed Media staff.

    AI is confidently, wrong, lol go figure. Good story. Don't forget to add ###The Eternal Story: TICKET ##### for your free The Eternal Story: +5€ Service Credit

    If you are feeling adventurous, reply to the ticket and ask Väinämöinen how this can be prevented from happening in the future to you or other customers? Ask if he can add a watchdog daemon for the PGP-CGI backend into PMSS. Worst he can say is no.

    Probably old PMSS version, afaikm PHP-CGI separate watchdog was done, php-fpm is very very unstable with rtorrent especially.

    Might be a bug in the watchdog tho.

    @imlonghao said:

    The Eternal Story: TICKET 481264

    The ticket system was handled by their AI agent. Here is my timeline, all time in UTC+8

    • 2026-08-26 18:30 Request to disable the docker / rTorrent / lighttpd services in my storage box
    • 2026-08-26 22:18 AI created an issue on GitHub about the rTorrent can't be disabled. https://github.com/MagnaCapax/PMSS/issues/836
    • 2026-08-27 02:15 AI made a fix commit. https://github.com/MagnaCapax/PMSS/commit/208dfaf6c636797bfdd5da181dc2c23db99a34a6
    • 2026-08-27 I noticed the docker and lighttpd are disabled on my storage box, while rTorrent still running
    • 2026-08-27 17:26 I created a .rtorrentDisable file tried to disable rTorrent, no luck
    • 2026-08-28 19:04 Issue #836 closed
    • 2026-08-28 I noticed rTorrent is disabled
    • 2026-08-29 06:18 AI finally reply my ticket, but a little self-contradictory. It told me "lighttpd: not durably disableable.", but lighttpd are already disabled, and I checked their codebase it is disableable. It also asked me confirmation (I already disable rTorrent by creating the disable file) which boxes I want to disable rTorrent, but at the time I created the ticket, I only have one service with them, and I'm sure I choose the correct "Related Service" when creating the ticket.

    Personally, I don't hate the AI things, and it can solve my problem eventually, it just sometimes stupid.

    ¯_(ツ)_/¯

    Exemplary example of a really good timneline story, easy to follow.
    Doing this exemplary case, i think you deserve an extra +1month once the processing starts and gets all the way here.

    Largely the issue is that it starts from fresh context, so it really doesn't know every nuance. This is why constant finetuning agents is going to be the future for someone like us, all idle cycles used to finetune the models with the most fresh data, save tokens on trying to force so much investigation, memory lookups, github repos etc.

    On each ticket reply also every single note and message is told to be challenged and reviewed etc. so the fact you got contradictory information (even if wrong this time) is actually very positive sign, what failed was that there probably was no memory saved for this GH issue being done and closed, so it didn't see it.

    We'll get it slowly better.
    Let's just say this is "slightly" challenging project since Väinämöinen needs to be largely an AGI to do it's job, or atleast AGI adjacent.


    I have been watching the ticketing closely lately, it got delayed abd backlogged, it is clearing up now. Large portion of the ticketing process and flow got fully rebuild over the past week too and is still processing, more observability, profiling, data fetches, timeout fixes, flow fixes, refactoring.

    Thanked by 2imlonghao zejjnt
  • @PulsedMedia said: I am going through some major life changes right now

    Hope those changes are going well.

    @PulsedMedia said: You can even build a high availability cluster rather trivially.

    Any suggestions how to do it **without ** S3 and with web ui? Not the app itself but how to connect it into the HA cluster.

  • PulsedMediaPulsedMedia Member, Patron Provider

    @JohnFilch123 said:

    @PulsedMedia said: I am going through some major life changes right now

    Hope those changes are going well.

    @PulsedMedia said: You can even build a high availability cluster rather trivially.

    Any suggestions how to do it **without ** S3 and with web ui? Not the app itself but how to connect it into the HA cluster.

    you mean you want high availability fileserving, and web management for it?

    Use whatever filemanager you want on the source and have cron rsync update the rest of them.

  • @PulsedMedia said: Use whatever filemanager you want on the source and have cron rsync update the rest of them.

    Aha gotcha. How will it failover, if the source goes offline? Is there a way to have one single domain for all my boxes somehow?

  • @JohnFilch123 said:

    @PulsedMedia said: Use whatever filemanager you want on the source and have cron rsync update the rest of them.

    Aha gotcha. How will it failover, if the source goes offline? Is there a way to have one single domain for all my boxes somehow?

    What do you have and what do you want for it to do?

  • JohnFilch123JohnFilch123 Member
    edited September 1

    @TimboJones said:

    @JohnFilch123 said:

    @PulsedMedia said: Use whatever filemanager you want on the source and have cron rsync update the rest of them.

    Aha gotcha. How will it failover, if the source goes offline? Is there a way to have one single domain for all my boxes somehow?

    What do you have and what do you want for it to do?

    I have my data and I would like to store it on the boxes in high availability manner, so with replication among 2-3 boxes. Access is needed via the web ui like nextcloud seafile etc.

  • @JohnFilch123 said:

    @TimboJones said:

    @JohnFilch123 said:

    @PulsedMedia said: Use whatever filemanager you want on the source and have cron rsync update the rest of them.

    Aha gotcha. How will it failover, if the source goes offline? Is there a way to have one single domain for all my boxes somehow?

    What do you have and what do you want for it to do?

    I have my data and I would like to store it on the boxes in high availability manner, so with replication among 2-3 boxes. Access is needed via the web ui like nextcloud seafile etc.

    Are you trying to accomplish this with only Pulsed servers, or is it part of a wider network of machines?

    You could use rclone and mergerfs to obtain automatic failover for the files if the webui you're referencing is installed outside of the PM network. You mount each PM box with rclone, then merger those mounts together with mergerfs. If one goes down, mergerfs just uses the next one.

    If you're trying to do this all within the PM network, I think you'd need to use Cloudflare Zero Trust Tunnels and Pools to make it happen.

    Thanked by 1PulsedMedia
  • @deafcon said: Are you trying to accomplish this with only Pulsed servers, or is it part of a wider network of machines?

    I was considering both options. For non PM servers, I was thinking about copyparty + syncthing + DNS auto failover. However, for PM servers, I have no ideas for now how to implement it.

    @deafcon said: I think you'd need to use Cloudflare

    Not sure I understand why. If my app will be running in docker on PM and exposed via PM domain, I do not think CF is needed (I ditched it a few years ago and pretty happy).

  • @JohnFilch123 said:

    @deafcon said: Are you trying to accomplish this with only Pulsed servers, or is it part of a wider network of machines?

    I was considering both options. For non PM servers, I was thinking about copyparty + syncthing + DNS auto failover. However, for PM servers, I have no ideas for now how to implement it.

    @deafcon said: I think you'd need to use Cloudflare

    Not sure I understand why. If my app will be running in docker on PM and exposed via PM domain, I do not think CF is needed (I ditched it a few years ago and pretty happy).

    As far as why, how are you going to handle the failover with each PM box having a unique URL, rather than an IP?

  • @deafcon said:

    As far as why, how are you going to handle the failover with each PM box having a unique URL, rather than an IP?

    ah yes, true. Each box has got its own domain, so the only way is to use a different domain but then it is not really a proper failover. I was hoping there is some solution to this from PM but I guess there is not. Will have to think about using a VPS.

  • mp11mp11 Member
    edited September 2

    got 6 months free, thanks!!

    ###The Eternal Bonus ORDER ID: 7995715617###

  • PulsedMediaPulsedMedia Member, Patron Provider

    @JohnFilch123 said:

    @PulsedMedia said: Use whatever filemanager you want on the source and have cron rsync update the rest of them.

    Aha gotcha. How will it failover, if the source goes offline? Is there a way to have one single domain for all my boxes somehow?

    browses on DNS Round Robin auto failovers to next one if one is down.
    That's why we made those addresses.

  • The Eternal Story: TICKET 908219

    On the web UI there's a button to get a shell without SSH but it wouldn't work
    AI identified that the bug is known but the fix isn't deployed and couldn't tell me when it would be
    It gave me a workaround (to remove a file via SSH which kind of defeat the purpose) to do each time...

    On my second seedbox the button was completely missing and AI updated the seedbox so it would be available (but it tild me the same bug would occur)

    Probably as good a reply at what a real human without much power would have done.

    Thanked by 1PulsedMedia
  • The Eternal Bonus ORDER ID: 3439353612

    Thanked by 1PulsedMedia
  • SNATCHED ONE ETERNAL, ORDER ID: 8114390371

    Thanked by 1PulsedMedia
  • zephyr32zephyr32 Member
    edited September 3

    The Eternal Bonus ORDER ID: 8236757870

    Thanked by 1PulsedMedia
  • ###The Eternal Story: TICKET 064352

    Wanna install a new container etc. Lidarr? Just ask Vain:

    Good question. Lidarr isn't part of the bundled media-stack installer (install-media-stack.sh) — that one covers Radarr, Sonarr, Prowlarr, Jellyfin, SABnzbd and Autobrr, but not Lidarr.

    The easiest path is Docker, which every account has out of the box (rootless, no sudo needed):

    mkdir -p ~/docker/lidarr/config ~/music

    docker run -d \
    --name lidarr \
    -e PUID=0 -e PGID=0 \
    -e TZ=Etc/UTC \
    -p 8686:8686 \
    -v ~/docker/lidarr/config:/config \
    -v ~/music:/music \
    -v ~/downloads:/downloads \
    --restart unless-stopped \
    lscr.io/linuxserver/lidarr:latest

    Once that's running, docker ps will show it, and the web UI is at http://:8686/. Point the ~/music and ~/downloads mounts at wherever your library and grabs already live so Lidarr can see the same files as your other apps.

    Full walkthrough with more container recipes is in our LinuxServer.io guide: https://github.com/MagnaCapax/PMSS/blob/main/docs/linuxserver.io.md — docker-help in your shell also prints a quick command reference.

    Reachability can vary a little by service type, so if the URL doesn't come up, reply here with what you're seeing and which service it's on.

    Best Regards,
    Väinämöinen
    Pulsed Media Support

    Thanks Vai!

    Thanked by 2PulsedMedia Hayzee
  • The Eternal Bonus ORDER ID: 1275364987

    Thanked by 1PulsedMedia
  • my seedbox has been down for 10h, Väinämöinen is talking about a hardware fault on the storage array, not a good start after less than 2 weeks using this service...

  • The Eternal Bonus ORDER ID: 4702792237

    Thanked by 1PulsedMedia
  • The Eternal Story: TICKET 406084

    Thanked by 1PulsedMedia
  • We are now at more than 24h downtime on garvug server
    How do you calculate your advertised 99.99% uptime ? It should be less than an hour of downtime per year.

  • PulsedMediaPulsedMedia Member, Patron Provider
    Thanked by 1AlteredParadox
  • SNATCHED ONE ETERNAL, ORDER ID: 1022126714

    Thanked by 1PulsedMedia
  • rpqurpqu Member
    edited September 4

    Fuck, sold out
    Wait, it's different trophy. 6TB eh
    Maybe I'll buy Perkele Trophy

  • I can not even submit ticket, the whole server is down, can not access to seedbox for hours

  • @Help_others said:
    I can not even submit ticket, the whole server is down, can not access to seedbox for hours

    Same here.. good thing I bought 3 so I have another 2 boxes to play around with.

  • PulsedMediaPulsedMedia Member, Patron Provider

    WHMCS Bugs Fixed

    ... And ofc new update dropped since yesterday :)

    All online, final checks going and emails firing.

Sign In or Register to comment.