Awww man. Here I was thinking we were having a movie night.
this post was submitted on 23 Apr 2026
55 points (98.2% liked)
Selfhosted
56957 readers
803 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Right? I’ve got the original and the 90s version in Jellyfin on my home lab server. 🧟♂️
LOL
Zombies that stick around for more than a few seconds indicate a signal problem in the parent process, where its init is stuck in the "wait" state, so the entry remains in the PID table.
It could be harmless, but it could become a problem if you need the resources. Curl shouldn't be doing this on its own.
It could be harmless, but it could become a problem if you need the resources.
That's the thing. None of them are consuming resources. I guess I should just ignore them, but it irritates me when I start my server, to see zombie processes. Makes me think something is askew.
Zombie processes do not use resources, well, a little, it's basically an entry describing how it exited.
The parent process is the thing keeping the zombie entry open. Killing it's parent should work if they bother you.
Zombie processes do not use resources, well, a little, it's basically an entry describing how it exited.
Agreed, but a very poorly-written program having a hanging memory or disk write, or a file lock could become a problem, especially if hundreds or thousands of zombies are waiting for something.
that sounds like poor garbage collection in an application.
I've written software that had similar issues when writing to files and I failed to "close" the file after writing.
processes stay open, files stay open. 500 byte processes times 10000 orphaned process can make for a bad time.
No idea about your specific case, but in the past when I've had frequent zombies it's been due to some blocking network process; typically NFS mounts.
They don't use any resources, but I agree they're annoying and could indicate some underlying issue.
I would check for issues with I/O and network access, especially anything that happens at kernel level. Look for anything suspicious in dmesg.
due to some blocking network process; typically NFS mounts.
I'll check that out.
Zero zombies here. I have a couple of Debian servers and one repeatedly upgraded Ubuntu on noble numbat that I'm too lazy to migrate to Debian. None have zombies.
Do you run a DE? Mine are headless.
Do you run a DE?
I'm not familiar with the acronym. I'm going to assume Desktop Environment. My servers are all headless as well
Sorry. That is what I meant.
s'ok bro. I'm not on all cylinders today.
I got a few on my laptop but none on either of my long running homelab boxes (70-80 days uptime). On my laptop they all seem related to espeak, the tts program. Is there any pattern in what processes yours are from?
my long running homelab boxes (70-80 days uptime)
Ahh see I shut down my servers at night. I just couldn't justify having them run while I was sleeping, and since I am the only user.
Makes sense. I share my media library with 10-15 friends so there's usually a few streams late at night, and scrubs, container updates, and backups run early morning at like 2-4am.
I've never run into a situation where it's a problem. But I just checked one of my Ubuntu servers and don't have any. What were the processes doing? What do they belong to?
@BakedCatboy@lemmy.ml @frongt@lemmy.zip Most of them are from [curl] but one is from [health.sh]. I am assuming one of the docker containers uses curl in it's processes as I have not initiated any curl commands.
If you use containers with health checks (including with curl), you need to tell docker (or podman) to provide an init process to reap child processes. For docker that means providing --init when running a container. It's a pretty common problem.
What is their parent process?
Lots of these: Zombie PID: 230650 | Parent PID: 7791 | Parent Name: spawn-unnamed
Two of those: Zombie PID: 61072 | Parent PID: 7791 | Parent Name: bash
Lots of these: Zombie PID: 56798 | Parent PID: 7791 | Parent Name: health.sh
Lots of these: Zombie PID: 16761 | Parent PID: 7646 | Parent Name: curl
...and a box of naked lady tee's
What is 7791?
7791 7768 201 /usr/sbin/netdata -u netdat 8.8 0.5 01:49:50
Sounds like netdata doing health checks but not always reaping its children. If you can reproduce it, I'd file a bug report.
Seems like someone already did this:
https://github.com/netdata/netdata/issues/20565
Maybe upgrading will fix it?
Hey bro, thanks for the lead! I will read the issue report and check if netdata is current.
@ilyam8 - adding to it here, netdata does leave tons of zombies around, this is not a "cannot reproduce" (not sure why that tag was added without even the minimal response, and then removed needs triage on top of that, so this ticket just dies off) One simply needs a running netdata instance and let it run a while. With time, 1, three and then tens of zombies will be listed at login.