http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c1 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fbui@suse.com |paka@wahoo.no-ip.org Flags| |needinfo?(paka@wahoo.no-ip. | |org) --- Comment #1 from Franck Bui --- (In reply to patrick shanahan from comment #0)

changing runlevel from 3 to 5 or 5 to 3 drops mounts which are not in fstab.

How exactly were the mounts created initially ? Did you create mount unit files or did you simply use the mount command ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c3 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com Flags| |needinfo?(paka@wahoo.no-ip. | |org) --- Comment #3 from Franck Bui --- (In reply to patrick shanahan from comment #2)

plug drive in graphical target and tell device notifier to mount

have not tried using manual mount

Which desktop environment are you using (KDE, LXDC, ...) ? Are you sure the mounts get dropped when switching from runlevel 3 to 5 ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c5 --- Comment #5 from Franck Bui --- (In reply to Dr. Werner Fink from comment #4)

Just tested this with systemd 228 + fix for bug#966535 together with a nfs mount share. AFAICS from changing runlevels the mount point isn't dropped.

yes I did the same test and came to the same conclusion. I suspect a component part of Patrick's DE which deals with plugged/unplugged devices which gets killed (when the DE service is stopped) when switching from 5 -> 3. And I guess, the behaviour would be expected in this case. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c7 --- Comment #7 from patrick shanahan --- (In reply to Franck Bui from comment #5)

(In reply to Dr. Werner Fink from comment #4)

...

Just tested this with systemd 228 + fix for bug#966535 together with a nfs mount share. AFAICS from changing runlevels the mount point isn't dropped.

yes I did the same test and came to the same conclusion.

I suspect a component part of Patrick's DE which deals with plugged/unplugged devices which gets killed (when the DE service is stopped) when switching from 5 -> 3.

And I guess, the behaviour would be expected in this case.

That is not what happened previous. The mounts were *not* disconnected. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c10 --- Comment #10 from patrick shanahan --- (In reply to Dr. Werner Fink from comment #8)

(In reply to patrick shanahan from comment #7)

Does this mena that the fixed version 228 not only fix bug #966535 but also this one?

no, only reference. condition was discussed there iirc -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c13 --- Comment #13 from patrick shanahan --- Created attachment 667308 --> http://bugzilla.opensuse.org/attachment.cgi?id=667308&action=edit systemctl list-units | grep \\.mount -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c15 --- Comment #15 from patrick shanahan --- Created attachment 667310 --> http://bugzilla.opensuse.org/attachment.cgi?id=667310&action=edit systemctl show -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c17 --- Comment #17 from patrick shanahan --- (In reply to Franck Bui from comment #16)

(In reply to patrick shanahan from comment #9)

...

(In reply to Dr. Werner Fink from comment #6)

...

(In reply to Franck Bui from comment #5)

This could be, yes.

@ Patrick -- more informations is required on your report.

Please can you provide some more informations about your moount points and the devices used for those. What type of devices do you use and are those devices part of a special target?

runlevel 5 plug in external usb drive mount using device notifier

Could you tell us more about the last step ?

"device notifier" is applet on task bar

Do you know which exact compement is doing the mount ?

no

Again tell us which DE you're using.

plasma5

...

change to runlevel 3 mount is not there

/run/media/<user>/<drive-mount-point>

manually mount /mnt/<drive-mount-point> change to runlevel 5 mount is not there

This case is strange because mount units are not stopped when isolating a target...

Perhaps the mount point has been moved to /run/media/<user>/<drive-mount-point> ?

that is the normal mount point when device notifier is utilized. grepping for the device, "mount |grep sdb2" provides no output at *any* mount point. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c21 --- Comment #21 from patrick shanahan --- (In reply to Dr. Werner Fink from comment #20)

(In reply to patrick shanahan from comment #19)

For plasma I guess something like

/usr/bin/startplasmacompositor /usr/bin/kwin_wayland

also any process started by those processes may have stderr on this file I guess.

I see no processes re: plasmacompositor or wayland I have compositor off, I don't use "effects" :) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c25 --- Comment #25 from patrick shanahan --- (In reply to Dr. Werner Fink from comment #24)

Ahh ... that is simple (AFAIK the lxsession redirects this error messages elsewhere).

OK then watch in one konsole the file with

tail -f /home/paka/.xsession-errors-:0

and in an other do your test, that is changing the runlevel during an by the desktop automounted USB device.

full .xsession-errors-:0 here: http://wahoo.no-ip.org/~paka/.xsession-errors-:0 cannot do tail .... as systemd closes tty's when changing to runlevel 3 and to 5 and cannot maintain remote connection as systemd drops network connection when changing runlevels 5->3->5..... another suggestion?? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c29 patrick shanahan changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(paka@wahoo.no-ip. | |org) | --- Comment #29 from patrick shanahan --- (In reply to Franck Bui from comment #28)

(In reply to patrick shanahan from comment #27)

...

(In reply to Dr. Werner Fink from comment #26)

...

(In reply to patrick shanahan from comment #25) How this? AFAICS from my tests the fixed 228 does *not* close the tty's

then it hasn't been published: systemd-228-2.1.x86_64 closes tty's on all five of my local boxes.

Well it's going to take some time before the fix reaches Tumbleweed...

So now I'm not sure which version of systemd you were using from the beginning of your testing.

systemd-228-2.1.x86_64

This repo should contain the fixes:

http://download.opensuse.org/repositories/Base:/System/openSUSE_Tumbleweed/

Can you redo your test with systemd updated from it ?

yes

Specially the test which consists of mounting your USB drive from runlevel3 and do the switch to runlevel5. According to one of your previous comment your drive isn't mounted anymore.

Before doing this test, change the log level of systemd to "debug" with: $ systemd-analyze set-log-level debug

then after your test restore the previous log level to the default "info" and the the content of the journal.

runlevel 5, systemd-228-10.2, external usb sdb mounted at: /run/media/paka/TOSHIBA EXT /var/run/media/paka/TOSHIBA EXT (Don't know why it mounts two places) switch to runlevel 3 tty6 previously open is dropped, relogged on /dev/sdb is no longer mounted mounted /dev/sdb to /mnt/external/ systemctl isolate graphical.target tty6 remained open mount /mnt/external persisted systemctl isolate multi-user tty6 remained open mount /mnt/external persisted systemctl isolate graphical umount /mnt/external used "Device Notifier" applet to mount /dev/sdb2 mounted to 2 locations: /run/media/paka/TO.. /var/run/media/paka/TO.. systemctl isolate multi-user tty6 remained open /dev/sdb2 is no longer mounted journalctl --since "2016-03-03 12:00" > journal.logs.txt http://wahoo.no-ip.org/~paka/journal.logs.txt -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c31 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(paka@wahoo.no-ip. | |org) --- Comment #31 from Franck Bui --- (In reply to patrick shanahan from comment #29)

runlevel 5, systemd-228-10.2, external usb sdb mounted at: /run/media/paka/TOSHIBA EXT /var/run/media/paka/TOSHIBA EXT (Don't know why it mounts two places)

It's not mounted twice, /var/run is a symlink to /run.

switch to runlevel 3

tty6 previously open is dropped, relogged on /dev/sdb is no longer mounted

From your logs:

Mar 03 12:11:56 toshiba systemd[1]: multi-user.target: Trying to enqueue job multi-user.target/start/isolate Mar 03 12:11:56 toshiba systemd[1]: udisks2.service: Installed new job udisks2.service/stop as 19463 Mar 03 12:11:56 toshiba systemd[1]: udisks2.service: Changed stop-sigterm -> dead Mar 03 12:11:56 toshiba systemd[1]: udisks2.service: Changed running -> stop-sigterm Mar 03 12:11:56 toshiba systemd[1]: Stopping Disk Manager... as expected the service that mounted your USB disk was stopped because it's not part of the multi-user target. So this seems to work as intended. Are you sure that tty6 was open before switching from runlevel 5 to 3 ? Still from the logs: Mar 03 12:11:56 toshiba systemd[1]: autovt@tty6.service: Failed to load configuration: File exists Mar 03 12:11:56 toshiba systemd[1]: autovt@tty6.service: Trying to enqueue job autovt@tty6.service/start/fail -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 http://bugzilla.opensuse.org/show_bug.cgi?id=968727#c33 --- Comment #33 from Franck Bui --- (In reply to patrick shanahan from comment #32)

It may be "as intended", but mounts should not arbitrarily disappear. A mount is a mount and because "Device Notifier" or "Disk Manager" makes that mount is irrelivant and should endure runlevel changes. Expectation is the KEY here rather than "as intended" related to *what* app performs the mount. Dropping a mount w/o notice and w/o <user> direction is just plain *wrong*.

My point is that systemd stops the Disk Manager service because it's not part of the multi-user.target. And this part works as intended. The fact that the Disk Manager chooses to umount disks it has mounted previously because it's going to be stopped is up to this service not to systemd. The fact that the Disk Manager is not part of the multi-user target is also up to the service. So I'm going to edit the subject to reflect this and we should probably reassign this 'issue' to the udisk2 maintainer. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=968727 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|systemd-maintainers@suse.de |bnc-team-screening@forge.pr | |ovo.novell.com -- You are receiving this mail because: You are on the CC list for the bug.