[ale] Lab Workstation Mystery

[Jim Kinney]

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> 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> 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
>>
>>
>> _______________________________________________
>> Ale mailing listAle at ale.orghttp://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
>>
>>
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
>
> _______________________________________________
> Ale mailing listAle at ale.orghttp://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160425/77d1fc97/attachment.html>