|
probably hardware or drivers in a bad state and frankly, with graphics, it could be either
|
#
?
May 18, 2022 13:26
|
|
|
|
| # ? Apr 26, 2024 14:35 |
|
|
also, wine especially is an odd collection of software emulating an even weirder thing. if you're having trouble with it, do ps x | grep wine, there's probably a wineserver or some other poo poo still running that's waiting on something to happen, which sometimes prevents you from killing wine itself. i find "killall -9 wine wineserver winedevice.exe" works 100% reliably so far, but i'm sure there's other edge cases.
|
|
#
?
May 18, 2022 13:27
|
|
|
Sapozhnik posted:ideally firefox would support dbus activation, that way it could run as a user unit under systemd and have resource limits and io and vm prioritization applied to it. is there a reason it would need to run as a systemd unit? like, couldn't the launcher set up all the cgroups and stuff?
|
|
#
?
May 18, 2022 13:44
|
|
|
it needs to run outside the cgroup of the desktop shell or whatever else launched it. you don't want web browser vm exhaustion to lock up your desktop shell as well. so there needs to be a way to tell systemd "hey, launch this application in a separate cgroup outside of my own". dbus activation is the standard way of doing that for interactive applications.
|
|
#
?
May 18, 2022 14:05
|
|
|
Sapozhnik posted:it needs to run outside the cgroup of the desktop shell or whatever else launched it. you don't want web browser vm exhaustion to lock up your desktop shell as well. so there needs to be a way to tell systemd "hey, launch this application in a separate cgroup outside of my own". dbus activation is the standard way of doing that for interactive applications. 
|
|
#
?
May 18, 2022 14:38
|
|
|
Truga posted:also, wine especially is an odd collection of software emulating an even weirder thing. if you're having trouble with it, do ps x | grep wine, there's probably a wineserver or some other poo poo still running that's waiting on something to happen, which sometimes prevents you from killing wine itself. i find "killall -9 wine wineserver winedevice.exe" works 100% reliably so far, but i'm sure there's other edge cases. tbqh `killall -9 wineserver` works just as well so does `killall -9 firefox` when it decides to poo poo all over your memory pages e: too many l's! Beeftweeter fucked around with this message at 15:22 on May 18, 2022 |
|
#
?
May 18, 2022 14:47
|
|
|
also ps auxwww supremacy
|
|
#
?
May 18, 2022 14:48
|
|
|
2 ws is wide, unlimited, 3 does nothing lol but yes
|
|
#
?
May 18, 2022 14:53
|
|
|
Truga posted:2 ws is wide, unlimited, 3 does nothing lol lol true. i just use it because aux/www is very easy to remember same with ls -halF
|
|
#
?
May 18, 2022 14:57
|
|
|
Captain Foo posted:who needs they cpuuy ate
|
|
#
?
May 18, 2022 18:49
|
|
|
NihilCredo posted:kill -9 is more of a gentle suggestion than anything kill -9 is a pretty hardcore "gently caress-off and go home" that will kill any process not blocked on io. unfortunately if you're swapping, you're probably also frequently blocking on that swap disk io
|
|
#
?
May 18, 2022 19:07
|
|
|
processes blocked by IO have been killable for like 15 years now
|
|
#
?
May 18, 2022 19:21
|
|
|
I've had games loving up but can say hitting "cancel" in steam almost always closes it; otherwise you can (need) to trace all the processes proton is spawning to kill it properly with just 'kill'. Grepping for the game isn't enough, its usually like 5 or 6 processes to low, same with wine though usually wine is enough for steam to reap the rest of the processes 
|
|
#
?
May 18, 2022 19:22
|
|
|
i enjoy the level of commitment to os compatibility that makes Proton put frozen direct3d applications on top of every other application, including any applications you might use to kill them fortunately it is possible to switch virtual desktops at least.
|
|
#
?
May 18, 2022 19:28
|
|
|
pseudorandom name posted:processes blocked by IO have been killable for like 15 years now killable in that you can fire off the sigkill and it will eventually be processed, but the process won't actually be killed, and you won't get back system resources until it exits that uninterruptible sleep. the big change in the last 15 years is that everyone has an ssd and you're way less likely to see processes in a D state unless hardware is hosed
|
|
#
?
May 18, 2022 19:29
|
|
|
no, TASK_KILLABLE was introduced to be a TASK_UNINTERRUPTIBLE that accepted lethal signals the reason why TASK_UNITERRUPTIBLE didn't take signals was purely an issue of backwards compatibility -- applications didn't expect to receive signals in uninterruptible sleep, so the kernel didn't deliver them, but applications can't handle lethal signals to begin with so there's no compatibility issue
|
|
#
?
May 18, 2022 19:53
|
|
|
Or unless you have an NFS mount. I had really some old system that some dolt had configured hard NFS mounts on (no intr either) and when the NFS server became unavailable entire trees on the file system became tar pits that I had to carefully avoid because even an accidental tab complete would lock the shell forever. The infrastructure I encountered when I started that job still infuriates me. One part of the infra also used LDAP, a single Windows DC, Samba localdb, and motherfucking NIS, all in the same lab.
|
|
#
?
May 18, 2022 19:55
|
|
|
pseudorandom name posted:no, TASK_KILLABLE was introduced to be a TASK_UNINTERRUPTIBLE that accepted lethal signals code:
|
|
#
?
May 18, 2022 20:05
|
|
|
you need to grep for _killable
|
|
#
?
May 18, 2022 20:14
|
|
|
i most certainly do not
|
|
#
?
May 18, 2022 20:17
|
|
|
sigkill no.5
|
|
#
?
May 18, 2022 21:36
|
|
|
pseudorandom name posted:you need to grep for _killable fair enough, that brings in 95 instances of it being used (compared with 300 now for _uninterruptible). my point stands that io through chunks of usb, md, scsi, and other common io subsystems can in fact leave a process uninterruptible. sure, there may be a better way for those drivers to do it, but they aren't yet.
|
|
#
?
May 18, 2022 21:46
|
|
|
just stop scheduling the process what could go wrong
|
|
#
?
May 18, 2022 21:50
|
|
|
also if a process triggers a kernel oops then killing it does nothing. you have to reboot the system to clear it out.
|
|
#
?
May 18, 2022 22:05
|
|
|
nudgenudgetilt posted:fair enough, that brings in 95 instances of it being used (compared with 300 now for _uninterruptible). this is true and since most chromebooks use eMMC it loving blows luckily my newest one uses a (replaceable) nvme ssd 
|
|
#
?
May 18, 2022 22:19
|
|
|
cron: hmm, yase let me just google which magic * does the thing I want in my crontab. I sure do love not knowing if the job succeeded. And manual triggering my task??? Who would ever want that. Also it rules when I have to go hunting for the stdout/stderr in whatever random place they wind up. Maybe I can have cron helpfully email me the results. systemd timers: just works. Boring and easy.
|
|
#
?
May 19, 2022 16:18
|
|
|
Maybe you just need to read the 15 man pages again, cron has been a rock solid platform since Jared Bedwetter wrote it for UNIX 1.3 in 1964 
|
|
#
?
May 19, 2022 16:21
|
|
|
hmm yeah let me just google "how to do my job". that'll show those idiot nerds,
|
|
#
?
May 19, 2022 16:29
|
|
|
the unix philosophy is when you have a bunch of tools written 50 years ago for what would today be considered a microcontroller, none of which have any sort of consistency or overarching design philosophy whatsoever.
|
|
#
?
May 19, 2022 16:40
|
|
|
you don't need consistency when you can pipe them through a dozen different plaintext processing programs to extract what you need
|
|
#
?
May 19, 2022 16:55
|
|
|
there is a crontab man page, op. also, if you configure it right, cron e-mails you the standard output. So you can easily write a script that is quiet unless an error occurs. cron is like vi. not everyone likes it, but it just works and it has its fans.
|
|
#
?
May 19, 2022 17:07
|
|
|
sb hermit posted:there is a crontab man page, op. email. as the primary mechanism to report the output and status of scheduled jobs. in 2022. email. email. WHAT THE gently caress IS WRONG WITH YOU?
|
|
#
?
May 19, 2022 17:09
|
|
|
nothing involving emailing me can be considered "properly configured" efb
|
|
#
?
May 19, 2022 17:09
|
|
|
You can also write a tiny python script that sends you a Slack message.  Edit* You can also use bash + curl to send Slack messages. FlapYoJacks fucked around with this message at 17:14 on May 19, 2022 |
|
#
?
May 19, 2022 17:10
|
|
|
Jonny 290 posted:nothing involving emailing me can be considered "properly configured" we’ll just hook it into your pagerduty notifications
|
|
#
?
May 19, 2022 17:11
|
|
|
you just lost a friend, foo
|
|
#
?
May 19, 2022 17:34
|
|
|
FlapYoJacks posted:You can also write a tiny python script that sends you a Slack message. or sms, or a mobile notification, or... yeah, there's a lot of poo poo you can script
|
|
#
?
May 19, 2022 17:39
|
|
|
unwinding after a long day by reading email reports about my scheduled computer tasks
|
|
#
?
May 19, 2022 17:45
|
|
|
Love to reinvent the wheel for 5 decades janitoring my cron jobs just to get notified my yospos archiver is a piece of poo poo
|
|
#
?
May 19, 2022 17:51
|
|
|
|
| # ? Apr 26, 2024 14:35 |
|
|
in my experience, usually when poo poo fails it's because a network's down somewhere and postfix will still deliver your message to the mailbox when it's back up, while you're python/curl script won't that's not to say you shouldn't try sending not-mail notifications, but mail is the perfect fallback
|
|
#
?
May 19, 2022 17:56
|
|