Re: [systemd-devel] systemd-logind failing due to dbus error on org.freedesktop.systemd1

2018-01-31 Thread Gustavo Sousa
On Wed, Jan 31, 2018 at 3:52 PM, Michal Koutný  wrote:
>
>
> On 01/31/2018 03:55 PM, Gustavo Sousa wrote:
>> Unfortunately, no. I didn't actually wait for the auto restart, I
>> tried myself with 'systemctl restart systemd-logind'.
> It seems like systemd-logind was thus properly connected to dbus and
> there may be other issue.
>
> Could you please post logs preceding the snippet you sent previously?
> (It seems something must went wrong at/before 8:38:51.)
I looked at the logs preceding that, but they logged the same error
(probably due to retries and me logging in?).
Then I decided to look at the logs from the beginning and realized a
different systemd error message (the snippet can be checked at
https://pastebin.com/kcAVcUQz):

Jan 30 14:18:09 systemd[1]: Failed to subscribe to NameOwnerChanged
signal for 'org.freedesktop.login1': Connection timed out

I also noticed that

> Also since it
> happened after reboot and systemd-logind restart didn't help, does it
> mean it's reproducible or still present?
Yes, it is still present. About it being reproducible, it is in my
environment, but I'm not sure how easily that could be reproduced in a
different environment.

> Can you see 'org.freedesktop.systemd1' name owned in the `busctl` output?
I'm not really familiar with dbus, but if by "owned" you mean that it
does have a process associated to it, then I would say no. Here is a
link for the output of `busctl`  https://pastebin.com/VqT38tya


> Does `kill -SIGUSR1 1` help you?
Nope. The issue persists (and the output of `busctl` keeps the same).

Regards,
Gustavo Sousa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-logind failing due to dbus error on org.freedesktop.systemd1

2018-01-31 Thread Michal Koutný


On 01/31/2018 03:55 PM, Gustavo Sousa wrote:
> Unfortunately, no. I didn't actually wait for the auto restart, I
> tried myself with 'systemctl restart systemd-logind'.
It seems like systemd-logind was thus properly connected to dbus and
there may be other issue.

Could you please post logs preceding the snippet you sent previously?
(It seems something must went wrong at/before 8:38:51.) Also since it
happened after reboot and systemd-logind restart didn't help, does it
mean it's reproducible or still present?

Can you see 'org.freedesktop.systemd1' name owned in the `busctl` output?

Does `kill -SIGUSR1 1` help you?

Thanks,
Michal



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-logind failing due to dbus error on org.freedesktop.systemd1

2018-01-31 Thread Gustavo Sousa
Hi, Michal.

On Wed, Jan 31, 2018 at 12:44 PM, Michal Koutný  wrote:
>
> Hello Gustavo.
>
> On 01/31/2018 03:36 PM, Gustavo Sousa wrote:
> > After a system upgrade,
> Was dbus-daemon restarted as part of the upgrade?

No, but I did reboot the system.

>
> > I've posted the output of 'journalctl -xe' regarding the error
> > here: https://pastebin.com/TNmg2z9s 
> Was it fixed when systemd-logind was (auto) restarted?

Unfortunately, no. I didn't actually wait for the auto restart, I
tried myself with 'systemctl restart systemd-logind'.

--
Gustavo Sousa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-logind failing due to dbus error on org.freedesktop.systemd1

2018-01-31 Thread Michal Koutný
Hello Gustavo.

On 01/31/2018 03:36 PM, Gustavo Sousa wrote:
> After a system upgrade, 
Was dbus-daemon restarted as part of the upgrade?

> I've posted the output of 'journalctl -xe' regarding the error
> here: https://pastebin.com/TNmg2z9s 
Was it fixed when systemd-logind was (auto) restarted?

Michal



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-logind failing due to dbus error on org.freedesktop.systemd1

2018-01-31 Thread Gustavo Sousa
Hello, everyone!

I'm having a problem regarding systemd-logind service. After a system
upgrade, I realized logging into the system took a long time, then I looked
at the system logs and noticed that systemd-logind service had failed.

I've posted the output of 'journalctl -xe' regarding the error here:
https://pastebin.com/TNmg2z9s

I'm using systemd version 236.81-1. My distro is Arch Linux. Output of
'uname -a':

Linux  4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25
UTC 2018 x86_64 GNU/Linux

Thanks in advance!

Regards,
Gustavo Sousa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Systemd User Service Not Starting with ecryptfs

2018-01-31 Thread Max Ehrlich
Andrei,

Amazingly it seems like the solution was that simple, thanks for your help.
I'm going to let the Ubuntu guys know those should probably be swapped

thanks again,
Max

On Tue, Jan 30, 2018 at 10:20 PM Andrei Borzenkov 
wrote:

> 31.01.2018 00:42, Max Ehrlich пишет:
> > Andrei,
> >
> > Honestly I just clicked "encrypt my home folder" on the GUI install a few
> > months ago. I'm trying to figure out what method ububtu uses by poking
> > around, but if you know how I can check please let me know
> >
> > Thanks for your
>
> I checked /etc/pam.d/common-session on Ubuntu 16.04 and pam_systemd
> comes before pam_ecryptfs. You may try to swap these lines.
>
> session optionalpam_systemd.so
> session optionalpam_ecryptfs.so unwrap
>
>
> response,
> > Max
> >
> > On Tue, Jan 30, 2018, 13:09 Andrei Borzenkov 
> wrote:
> >
> >> 30.01.2018 18:21, Max Ehrlich пишет:
> >>> I use home folder encryption with ecryptfs. I also want to start
> >> gpg-agent
> >>> when I login using a user service. No matter what I try, I can't get
> this
> >>> to work because it seems like systemd deosnt wait for the decryption to
> >>> happen. Is there any support for this configuration or can my user
> >> services
> >>> be stored someplace else?
> >>>
> >>
> >> How exactly you decrypt home - PAM integration (pam_ecryptfs, pam_mount,
> >> ??) or something else?
> >>
> >> I suppose when using PAM it /may/ work if PAM module responsible for
> >> ecryptfs comes before pam_systemd.
> >>
> >
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-31 Thread Franck Bui
On 01/24/2018 04:33 PM, Lennart Poettering wrote:
> I am not convinced the reasoning is convincing for such a major change
> (I mean, let's not forget that systemd's current behaviour has been
> around for more than half a decade too already). If you want other
> bits of the code not to interfere what you are doing, then take the
> BSD lock and all will be good, it's the right, the better thing to do,
> and you have to do it anway. It will not only stop systemd from
> interfering but everything else too...

Lennart, would you accept such changes ?

 1. introduce a new option for mount units that turn ON/OFF
the automatic mount feature systemd introduced.

 2. make fstab-generator uses this option if "noauto" is not
used. This would have the benefit to explicitly see if this
option is used when reading a mount unit file and make it
available for those who directly created mount units.

 3. make a compile option (--compat-sysv-fstab or such) which
would turn the automatic mount feature OFF by default for
mount units generated by fstab-generator.

 4. introduce a new kernel command line switch to override the
default (whatever its value).

 5. introduce a new fstab option "x-systemd.auto" or such that
would override 3. and 4.

At least distros would be free to choose if they want to turn the
feature ON by default. And the adding of new options would clarify the
current situation IMHO.

Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel