On 2014-04-28 05:50, Michael Biebl wrote:
You can also inspect the units via
systemctl status foo.{device,service,...}
dev-mapper-common.device
Loaded: loaded
Active: inactive (dead)
Apr 29 10:23:43 kiwi systemd[1]: Job dev-mapper-common.device/start
timed out.
Apr 29 10:23:43 kiwi systemd[1]: Timed out waiting for device
dev-mapper-common.device.
systemctl show foo.{device,service,...}
Id=dev-mapper-common.device
Names=dev-mapper-common.device
Wants=mnt-common.mount
BoundBy=mnt-common.mount
Before=mnt-common.mount
Description=dev-mapper-common.device
LoadState=loaded
ActiveState=inactive
SubState=dead
InactiveExitTimestampMonotonic=0
ActiveEnterTimestampMonotonic=0
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=no
CanStop=no
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureIsolate=no
IgnoreOnIsolate=yes
IgnoreOnSnapshot=yes
NeedDaemonReload=no
JobTimeoutUSec=1min 30s
ConditionTimestamp=Tue 2014-04-29 10:22:13 PDT
ConditionTimestampMonotonic=24607903
ConditionResult=yes
Eventually I just figured that sytemd shouldn't be doing anything with
/mnt/common and went looking for why it would be doing so.
One other thing, in case somebody with a similar problem finds
this--after fixing my /etc/fstab, I had to reboot, or else systemd would
keep trying the same bad unit. I suppose there's probably a way to make
systemd regenerate them, but I don't know it.
-Corey
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ff5b3.5060...@fatooh.org