378
top 44 comments
sorted by: hot top controversial new old
[-] deadcream@sopuli.xyz 73 points 1 month ago

That's why you launch them through systemd.

[-] ikidd@lemmy.world 72 points 1 month ago

But systemd is the devil and makes nothing better, right?

Right?

[-] tdawg@lemmy.world 18 points 1 month ago

Really? I've never had issue with it

[-] qaz@lemmy.world 35 points 1 month ago

It's a joke about the criticism systemd gets

[-] desktop_user@lemmy.blahaj.zone 7 points 1 month ago
[-] introvertcatto@lemmy.blahaj.zone 24 points 1 month ago

Openrc is bloat, you should manually pair electrons

[-] bleistift2@sopuli.xyz 8 points 1 month ago

The constant nagging by you systemd people worked. I’ve written a unit that does what I need it to do. That was more annoying than I think it needed to be, but well… my solution didn’t work at all.

[-] deadcream@sopuli.xyz 5 points 1 month ago

AFAIK kernel itself doesn't send any signals to processes on shutdown/reboot, it just stops executing them. This is a job service manager (e.g. systemd) that terminates processes using SIGTERM before asking kernel to shutdown.

[-] tatterdemalion@programming.dev 43 points 1 month ago* (last edited 1 month ago)

You are never guaranteed to be able to do anything during a crash. You are better off handling these kinds of edge cases in a recovery phase during the start of your app.

[-] bleistift2@sopuli.xyz 25 points 1 month ago

It’s not a crash. It’s a graceful shutdown. I expected that to also shutdown my app gracefully.

I’m actually trying to store the program state that hasn’t been persisted yet to disk. Good luck doing that after the next boot.

[-] chonglibloodsport@lemmy.world 5 points 1 month ago

Persist everything to disk in real time. When the signal hits exit immediately.

[-] bleistift2@sopuli.xyz 8 points 1 month ago

Persist everything to disk in real time.

That’s the thing I’m trying to avoid.

[-] barsoap@lemm.ee 3 points 1 month ago* (last edited 1 month ago)

Easier to do than to get never-exercised edge-case code to work flawlessly. Are you sure you can't just throw sqlite at the problem? It's often overkill but, hey, it's there on the shelf, might as well use it and I've seen it out-perform hand-rolled data structures. Non-persistent ones, written by very confident C coders. And remember crashes are unavoidable, if nothing else then someone can trip over the power cord.

[-] bleistift2@sopuli.xyz 2 points 1 month ago* (last edited 1 month ago)

You can’t know that from my issue description, but throwing a database at that problem really is ridiculous overkill.

Still thanks for the suggestion

[-] barsoap@lemm.ee 1 points 1 month ago* (last edited 1 month ago)

It's mostly about throwing ACID at the problem, sqlite just happens to be battle-tested to a ludicrous degree, it's light enough to not be unconscionable overhead in simple situations (unless you're on embedded), and performant enough to also deal with nastier situations so I prefer it over some random K/V store with the same guarantees. It's also a widely-used and stable data format which might come in handy.

That said, if you want to go lightweight do consider good, ole, POSIX filesystem guarantees, in particular that mv is atomic (as long as you stay on the same filesystem but that's easy to ensure by mv'ing within a directory). That's not durable on its own, you'll need to fsync for that, and consistency and integrity is up to your code.

[-] chonglibloodsport@lemmy.world 1 points 1 month ago

Admittedly it’s very difficult if you want to maintain consistency but the benefits are enormous!

[-] barsoap@lemm.ee 3 points 1 month ago* (last edited 1 month ago)

Crash-only software. To be resilient you need some kind of ACID anyway which means that you can let go of your shutdown procedure and just send yourself SIGKILL instead.

[-] FrostyCaveman@lemm.ee 28 points 1 month ago

This is legitimately the best usage of this meme I’ve seen in years. Termination signals hnnngg

[-] PotatoesFall@discuss.tchncs.de 7 points 1 month ago* (last edited 1 month ago)

How are you running your script?

(I have no idea how to solve your issue I'm just asking questions to sound smart and helpful)

[-] bleistift2@sopuli.xyz 8 points 1 month ago

It’s a node process invoked by a run.sh, which gets executed via a .desktop file in the ~/.config/autostart directory.

I went with a systemd unit now and it works.

[-] sik0fewl@lemmy.ca 8 points 1 month ago* (last edited 1 month ago)

I can't remember off the top of my head, but your shell script might not be relaying the SIGTERM. Make sure you start your node process with the "exec" statement. This will replace the script's process with node instead of having node be a subprocess of your script.

[-] bleistift2@sopuli.xyz 3 points 1 month ago

When I run the script myself and kill it, it gets the signal and acts correctly. Only when I poweroff the system, this doesn’t work.

I also tried prepending exec, but no dice.

[-] RustyShackleford@programming.dev 3 points 1 month ago

"SyStEmD iS bLoAt..."

[-] marcos@lemmy.world 1 points 1 month ago

Your DE may be the one not relaying the sigterm, or it may be losing the PID because of the double launching.

Does the LSB have something to call on termination? Or you may want to call an executable there instead of a script.

[-] Arghblarg@lemmy.ca 7 points 1 month ago

Can't SIGTERM be observed to react to a poweroff?

[-] bleistift2@sopuli.xyz 3 points 1 month ago

That’s what I thought, but my program never receives the signal.

[-] nintendiator@feddit.cl 2 points 1 month ago

That might be an issue with who invokes your program.

[-] sunshine@lemmy.ml 6 points 1 month ago
[-] bleistift2@sopuli.xyz 4 points 1 month ago* (last edited 1 month ago)

~~It turns out I’m getting SIGCHLD. It might be related to how my script is started – it is a bash script that starts a node process and is itself run by Cinnamon’s (?) startup applications feature.~~

Wrong; still investigating

[-] Illecors@lemmy.cafe 5 points 1 month ago

I realise I'm late to the party and you've alreadu gone the systemd unit way, but had your script trapped sigterm to begin with?

[-] bleistift2@sopuli.xyz 5 points 1 month ago

When I run the script myself and kill it, it gets the signal and acts correctly. Only when I poweroff the system, this doesn’t work.

[-] nous@programming.dev 7 points 1 month ago

SIGINT is sent when you press Ctrl+C. SIGTERM is sent in just about every other situation - basically when the system wants the program to end. For instance when systemd wants to stop the service or the default signal with programs like kill pkill htop etc. You should catch both of these signals.

[-] bleistift2@sopuli.xyz 2 points 1 month ago

I did try to catch all of these signals:

                | "SIGABRT"
                | "SIGALRM"
                | "SIGBUS"
                | "SIGCHLD"
                | "SIGCONT"
                | "SIGFPE"
                | "SIGHUP"
                | "SIGILL"
                | "SIGINT"
                | "SIGIO"
                | "SIGIOT"
                | "SIGKILL"
                | "SIGPIPE"
                | "SIGPOLL"
                | "SIGPROF"
                | "SIGPWR"
                | "SIGQUIT"
                | "SIGSEGV"
                | "SIGSTKFLT"
                | "SIGSTOP"
                | "SIGSYS"
                | "SIGTERM"
                | "SIGTRAP"
                | "SIGTSTP"
                | "SIGTTIN"
                | "SIGTTOU"
                | "SIGUNUSED"
                | "SIGURG"
                | "SIGUSR1"
                | "SIGUSR2"
                | "SIGVTALRM"
                | "SIGWINCH"
                | "SIGXCPU"
                | "SIGXFSZ"
                | "SIGBREAK"
                | "SIGLOST"
                | "SIGINFO";
[-] phoenixz@lemmy.ca 1 points 1 month ago

Good luck trapping the SIGKILL signal

[-] blind3rdeye@lemm.ee 3 points 1 month ago

My computer has a problem where occasionally it will become completely unresponsive. (Mouse cursor doesn't move. Keys have no apparently effect. Whatever app is running freezes. I think its a hardware problem with the graphics card, but I don't know what. Logs at the time it freezes say "the GPU has fallen off the bus".)

Anyway... I recently learnt about Magic SysRq. And I've been able to shutdown the computer from this unresponsive state with SysRq, R E I S U O. Where as I understand it, the "E" tells processes the end nicely if they can; and then the "I" just ends them by force.

(At this point, I'm realising that the E is SIGTERM, not SIGINT - so that screws up the relevance of my story; but I figure I'll keep going anyway.)

The point is, I've been using key combo with a nice pause between each key, thinking there was some chance that processes might be ending gracefully. But when I tried it while the computer wasn't frozen, the computer was able to inform me that the E and I commands were disabled. (I don't know why.) So even though I wanted to give a nice "please end" signal, in the end that just wasn't happening.

[-] ProgrammingSocks@pawb.social 1 points 1 month ago

You could try enabling systemd-oomd. It's a userspace OOM killer and seems to be aggressive enough to mostly stop that from happening.

[-] skuzz@discuss.tchncs.de 2 points 1 month ago

I didn't know why a person would go to these lengths to deal with a misbehaving computer, as compute devices are generally for work, and need to work in order to do work, and any kind of crash is going to get my entire focus until it is banished to Hades...

...but then, learned something along the way I probably otherwise would not have, because of @bleistift2@sopuli.xyz's tenacity.

[-] Grandwolf319@sh.itjust.works 1 points 1 month ago

Missed opportunity to make the last panel have her eyes closed (or just be fully black).

[-] Maddier1993@programming.dev 1 points 1 month ago

I thought someone here had mentioned that the environment and user executing the script at startup and you running the script might have differences. The reason it would have worked with systemd might be that the environment was loaded correctly?

[-] bleistift2@sopuli.xyz 1 points 1 month ago

Why should the environment make a difference when it comes to receiving the SIGINT when the process gets killed?

[-] KairuByte@lemmy.dbzer0.com 2 points 1 month ago

They responded to the wrong post. They’re likely thinking of the auto start post.

[-] Maddier1993@programming.dev 1 points 1 month ago

Oops yeah you're right. Sorry OP. There's nothing better than using a database that flushes to disk often enough that missing a small chunk of data due to interruptions should be fine. Probably some kind of memory mapped IO on top of eager writing filesystem should do a good enough job.

[-] PoolloverNathan@programming.dev 1 points 1 month ago
[-] bleistift2@sopuli.xyz 2 points 1 month ago* (last edited 1 month ago)

~~nope, SIGCHLD.~~ Wrong.

But thanks.

this post was submitted on 25 Dec 2024
378 points (99.2% liked)

Programmer Humor

20033 readers
618 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS