[ale] Lab Workstation Mystery
DJ-Pfulio
djpfulio at jdpfu.com
Mon Apr 25 08:42:40 EDT 2016
Just to clarify, not all Ubuntu systems work that way. On a 14.04 box:
$ psg systemd
root 31358 1 0 Apr16 ? 00:00:01 /lib/systemd/systemd-udevd --daemon
root 31427 1 0 Apr16 ? 00:00:00 /lib/systemd/systemd-logind
Zero ibus stuff. Way too many dbus things.
message+ 810 1 0 Apr10 ? 00:00:01 dbus-daemon --system --fork
That's all.
I only run LTS, so don't have any 15.xx to check. Need to install a play 16.04
this week to see what they've done this time. Heard they removed all the
external amazon data transfers as the default, finally.
On 04/25/2016 07:25 AM, Jim Kinney wrote:
> I checked my centos 7 and fedora 23 systems. They don't spawn off as user owned
> processes. In fact, they don't fork at all. The systemd processes handle the
> needs directly.
>
> I find it very odd that ubuntu and centos have such very different systemd
> methodology.
>
> On Apr 24, 2016 11:48 AM, "Todor Fassl" <fassl.tod at gmail.com
> <mailto:fassl.tod at gmail.com>> wrote:
>
> I'm at home this morning on an ubuntu 15.10 system with a local home
> directory and no autofs. Ps shows that all 4 of those processes are running
> for me -- systemd, (sd-pam), ibus-daemon, and ibus-dconf. BTW, I googled for
> sd-pam and it looks like that is a fork/rename of the systemd process
> intended to desstroy the session. ie., sd-pam means "session destroy pam".
> Apparently, when you fork/rename a process, you can rename it whatever you
> like including putting parens around the name. But those parens don't mean
> anything.
>
> I suspect ubuntu starts a per-user systemd process. The one thing that
> might be non-standard for my users is that the default window manager is
> gnome, not unity. I'll have to experiment with that. Another thing I'll have
> to try is to uninstall the screen reader. I've mentioned before that I am
> blind. You can press Alt+Super+s to start the screen reader at the lightdm
> login screen. I don't *think* that requires a special process to run unless
> you actually use the hotkey. Most of my end-users would not be firing up the
> screen reader so I doubt it has anything to do with that.
>
> But I'll have to do a straight up install of ubuntu and log in to unity as a
> local user and then log out. The log out part might be tricky. I might have
> to get sighted assistance to do that. Oh, as I write this, it occurs to me
> that there is probably a hotkey in unity to log out. So set up a plain
> vanilla system, log in, log out, and see if those processes hang around.
>
> On 04/23/2016 10:43 AM, Jim Kinney wrote:
>>
>> That is odd. I have systemd machines with automount and I don't see an
>> individual systemd process per user. On my centos7 workstations, I have
>> only a single systemd process for the systemd itself plus others named
>> like systemd-udevd, etc, and all are root owned.
>>
>> On Apr 23, 2016 11:36 AM, "Todor Fassl" <fassl.tod at gmail.com
>> <mailto:fassl.tod at gmail.com>> wrote:
>>
>>
>> The first thing I did was add that option to the nfs mount in the
>> autofs config. I thought it didn't work but back then I didn't have
>> as good of a handle on the problem as I do now. I found bug reports
>> related to the default timeout for aufs not working. The bug reports
>> said the timeout worked if you set itimplicitly for each share in the
>> autofs config files. But that turned out being another red-herring.
>>
>> I am pretty sure this is a systemd problem. I just did an experiment
>> -- I killed off the processes left over after a user logged out on 3
>> different workstations but I did not unmount their home directory.
>> Each of the 3 had the same 4 processes running, systemd,(sd-pam),
>> ibus-daemon, and ibus-dconf. All I did was kill off those 4 processes
>> and after the usual time, the automounter unmounted their home
>> directory. So I am about as sure as I can be that this is not an
>> automounter or nfs problem. It's systemd not killing off those
>> processes when a user logs out.
>>
>> Three days -- so far so good.
>>
>> On 04/22/2016 11:27 AM, Scott Plante wrote:
>>> This isn't a solution to the underlying problem, but you might want
>>> to consider the "soft" option for the NFS mount. By default, NFS is
>>> designed to act like a physical disk in the sense that once the user
>>> initiates a write, it will block at that spot until the write
>>> completes. This is great if you have a NAS unit in the next rack slot
>>> from your database server. However, if you don't need quite that
>>> level of write assurance, the "soft" option acts more like a typical
>>> remote network share. If a problem occurs, the writer will just get
>>> an I/O error and be forced to deal with it. You won't get the kind of
>>> system hanging you experience with hard mounts. If you're just saving
>>> documents and doing that kind of basic file I/O this is perfect.
>>> You're mounting home directories, so you're somewhere in between, but
>>> depending on what your users are actually doing, soft mounts may be
>>> for you. Again, this doesn't explain the whole re-mounting read-only
>>> behavior but it may still be helpful for you to look into.
>>>
>>> Scott
>>>
More information about the Ale
mailing list