Shell server adjustments

[ds_sonic_asif]

Incidentally, anyone who has taken an interest in the shell...how do you feel about the current environment, where the only processes you can see are your own?

Seems fine to me. I don't have a use case for needing to know about other users and other processes. The majority of my usage is occasionally feeding mini hosting via scp. Every blue moon or so I may ssh in to run some diagnostic from afar (e.g. nmap to see if I am unintentionally leaking access at home).

On the other hand, if the interactive ssh session was behaving oddly, I would probably run a handful of command line stats commands to see what was going on. It appears that df, vmstat, iostat, ifconfig, and probably others, are reporting system statistics.

[leondis]

Hi Scott:

Just wanted to say Thanks for getting the load avgs back down to a reasonable range. Login is no longer difficult.

As for not seeing others' processes, the only downside i can think of is that maybe unconsciously people think that they have the machine to themselves and are more likely to overload it because there's no sense that others are using it too. But other
than that i don't see a big deal one way or the other... though i used to "talk" to people i know sometimes when i saw they were online...

Thanks again

[scott]

Hi Scott:

Just wanted to say Thanks for getting the load avgs back down to a reasonable range. Login is no longer difficult.

As for not seeing others' processes, the only downside i can think of is that maybe unconsciously people think that they have the machine to themselves and are more likely to overload it because there's no sense that others are using it too. But other
than that i don't see a big deal one way or the other... though i used to "talk" to people i know sometimes when i saw they were online...

Thanks again

I've investigated what it would take to get talk running, it's a very retro thing that would be fun (even ytalk).

Load avg is creeping up again. I am monitoring it:



(That is on a tiny lilliput monitor sitting next to me at my desk.)

[apl]

Getting much worse again:
] uptime
13:41:56 up 2 days, 4:42, 0 users, load average: 4.79, 3.78, 3.51
] uptime
16:37:46 up 2 days, 7:38, 0 users, load average: 21.27, 21.67, 19.45

[scott]

Getting much worse again:
] uptime
13:41:56 up 2 days, 4:42, 0 users, load average: 4.79, 3.78, 3.51
] uptime
16:37:46 up 2 days, 7:38, 0 users, load average: 21.27, 21.67, 19.45

I've tracked it down to some user cron jobs and frequent (apparently scripted) remote commands.

Quick note[*], while on the subject: If you're ssh'ing in remote commands, please don't background them unless you have some kind of locking in place to prevent simultaneous execution. That's related to what's happening on the shell server, which has been stacking up a significant load average as it goes, since these user remote commands I just mentioned are being executed with '&' at the end of a long command line. That's legitimate in many cases, but you've got to use locking to prevent the next invocation of the remote command from messing up the previous...or the previous 2, or 3, or however many are getting stacked up and interfering with each other.

[*] "quick note" -- ch'yeah'right, that'll be the day

[apl]

Thanks Scott.
So basically, an unintentional DOS attack. Such are the risks of a shared server I guess.
Load has remained low since yesterday.
If the problem recurs, it looks like you might be able to set per-user CPU limits using systemd

[scott]

Okay, here's the skinny.

Kelsey wins the Internet for the day. He looked at the system and noticed there were a lot of mounts. That isn't unusual, since there are bind mounts galore in every person's chroot.

But this was a _lot_ of mounts. Way too many of them. We had xdg mounts over the top of xdg mounts. It was panic in the streets.

Anyway, we think we found the problem, should be (knock on wood) better.

-Scott

[scott]

https://imgur.com/fXUSyay

How is your Sunday morning going?

-Scott