Re: [systemd-devel] auto-unmount via BindsTo= is annoying
В Sat, 4 Apr 2015 12:55:34 +0300 Mantas Mikulėnas пишет: > On Sat, Apr 4, 2015 at 7:37 AM, Andrei Borzenkov > wrote: > > > В Fri, 3 Apr 2015 21:19:24 +0300 > > Mantas Mikulėnas пишет: > > > > > Previously udev used to undo mounts when a device *disappeared;* when > > > systemd took over the task, it started unmounting things as soon as it > > > noticed that the device *doesn't exist right now.* While similar, the new > > > behavior can be annoying, since it also triggers if the device never > > > existed in the first place. For example: > > > > > > ~ My fstab has "/dev/mapper/luks-backups → /mnt/backup". I want to mount > > > another disk there (which has a different label), but even though `mount > > > /dev/sdb1 /mnt/backup` succeeds, the directory remains empty and won't > > show > > > up in `findmnt`. > > > > > > After a few retries I check dmesg and notice systemd saying that > > > "mnt-backup.mount is bound to an inactive device; stopping". Which means, > > > if my fstab says disk X is mounted there, systemd won't let me mount > > > anything else but disk X at that location. > > > > > > ~ I had to boot to emergency mode due to reasons, and attempted to mount > > > /boot & /boot/efi in order to fix something. Since my fstab had > > > "/dev/disk/by-partlabel/boot → /boot", any attempts to mount anything at > > > /boot get immediately undone – emergency mode has no udev, so I get > > > "boot.mount is bound to an inactive device; stopping" all over again. > > > > > > > Do these commits help? > > > > commit 628c89cc68ab96fce2de7ebba5933725d147aecc > > Author: Lennart Poettering > > Date: Fri Feb 27 21:55:08 2015 +0100 > > > > core: rework device state logic > > > > commit 496068a8288084ab3ecf8b179a8403ecff1a6be8 > > Author: Martin Pitt > > Date: Fri Mar 13 08:35:59 2015 +0100 > > > > core: don't change removed devices to state "tentative" > > > > Nope, this is already on 093c2cfe3b1. > > I think the problem is dependent on unit load state (without claiming to fully understand how and when systemd evicts unit from cache). When mount unit is not in cache, systemd creates *new* definition and sets BindsTo current device where filesystem is currently mounted. If mount unit is present in cache, it already has some BindsTo. When systemd processes mountinfo it apparently neither removes old nor adds new BindsTo for new device. Which makes check kick in later. When system stops in emergency mode due to device not present, mount unit is kept loaded. Unfortunately, the only way to check for it is systemctl -a | grep because any attempt to explicitly list specific unit will trigger its loading, screwing up its Load state. I see multiple issues here a) it would be helpful if systemctl status/show could differentiate between unit loaded due to this systemctl call and unit having been loaded before. May be "--do-no-load" flag to systemctl or something like this. b) when systemd finds out that What is different in mountinfo, it should remove BindsTo for old What. May be it should really simply always drop old mount unit (present in cache) and build new one from scratch. Or push old definition (to support stacked mounts). c) The resulting unit should be clearly marked as different from definition on disk. I.e. bor@opensuse:~/src/systemd> systemctl status boot.mount boot.mount - /boot Loaded: loaded (/etc/fstab) Active: active (mounted) since Пт 2015-03-27 11:09:08 MSK; 1 weeks 1 days ago Where: /boot What: /dev/sda1 bor@opensuse:~/src/systemd> sudo mount /dev/mapper/ control system-docker system-root system-datastore system-home system-swap bor@opensuse:~/src/systemd> sudo mount /dev/mapper/system-docker /boot root's password: bor@opensuse:~/src/systemd> systemctl status boot.mount boot.mount - /boot Loaded: loaded (/etc/fstab) ^^^ Active: active (mounted) since Пт 2015-03-27 11:09:08 MSK; 1 weeks 1 days ago Where: /boot What: /dev/mapper/system-docker ^ That is obviously wrong. What is mounted now comes *NOT* from /etc/fstab, and it should not be claiming it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-219] Journal spamming by umount / high CPU usage
Lennart Poettering schrieb: >> To me it looks like the automounter tries to unmount unless there's still >> references open in the filesystem. It does, however, no try to do this >> after some timeout - which is fine. OTOH, this could be just an effect of >> the mount point forcibly vanishing because the USB device >> disconnected. > > The kernel actually allows unmounting of mounts at any time, even if > the backing device has vanished. (In fact, it particularly allows > unmounting in that case...) I had this case again. Since I wasn't booted with log_level=debug I simply turned the drive off, and now it gets intersting: Apr 04 16:25:26 jupiter umount[3678]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3684]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3803]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3815]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3817]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3845]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3883]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3905]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3938]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd-journal[436]: Suppressed 47447 messages from /user.slice/user-500.slice Apr 04 16:25:26 jupiter umount[3941]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd[817]: mnt-private-usb\x2dbackup.mount mount process exited, code=exited status=1 Apr 04 16:25:26 jupiter systemd[817]: Unit mnt-private-usb\x2dbackup.mount is bound to inactive unit. Stopping, too. Apr 04 16:25:26 jupiter systemd[817]: Unmounting /mnt/private/usb-backup... Apr 04 16:25:26 jupiter umount[3943]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd[817]: mnt-private-usb\x2dbackup.mount mount process exited, code=exited status=1 Apr 04 16:25:26 jupiter systemd[817]: Unit mnt-private-usb\x2dbackup.mount is bound to inactive unit. Stopping, too. Apr 04 16:25:26 jupiter systemd[817]: Unmounting /mnt/private/usb-backup... Apr 04 16:25:26 jupiter umount[3945]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd[817]: mnt-private-usb\x2dbackup.mount mount process exited, code=exited status=1 Apr 04 16:25:26 jupiter systemd[817]: Unit mnt-private-usb\x2dbackup.mount is bound to inactive unit. Stopping, too. Apr 04 16:25:26 jupiter systemd[817]: Unmounting /mnt/private/usb-backup... Apr 04 16:25:26 jupiter umount[3947]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd[817]: mnt-private-usb\x2dbackup.mount mount process exited, code=exited status=1 Apr 04 16:25:26 jupiter systemd[817]: Unit mnt-private-usb\x2dbackup.mount is bound to inactive unit. Stopping, too. Apr 04 16:25:26 jupiter systemd[817]: Unmounting /mnt/private/usb-backup... Apr 04 16:25:26 jupiter umount[3948]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt [...repeated a few times...] Apr 04 16:25:26 jupiter systemd[817]: Unmounting /mnt/private/usb-backup... Apr 04 16:25:26 jupiter umount[3959]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter umount[3961]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd[817]: mnt-private-usb\x2dbackup.mount mount process exited, code=exited status=1 Apr 04 16:25:26 jupiter systemd[817]: Unit mnt-private-usb\x2dbackup.mount is bound to inactive unit. Stopping, too. Apr 04 16:25:26 jupiter systemd[817]: Unmounting /mnt/private/usb-backup... Apr 04 16:25:26 jupiter umount[3963]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Apr 04 16:25:26 jupiter systemd[817]: mnt-private-usb\x2dbackup.mount mount process exited, code=exited status=1 Apr 04 16:25:26 jupiter systemd[817]: Unit mnt-private-usb\x2dbackup.mount is bound to inactive unit. Stopping, too. [...] Apr 04 16:25:26 jupiter systemd-journal[436]: Suppressed 11231 messages from /user.slice/user-500.slice Apr 04 16:25:26 jupiter systemd[817]: Failed unmounting /mnt/private/usb- backup. Apr 04 16:25:26 jupiter syste
Re: [systemd-devel] auto-unmount via BindsTo= is annoying
On Sat, Apr 4, 2015 at 1:44 PM, Andrei Borzenkov
wrote:
> В Sat, 4 Apr 2015 12:55:34 +0300
> Mantas Mikulėnas пишет:
>
> > On Sat, Apr 4, 2015 at 7:37 AM, Andrei Borzenkov
> > wrote:
> >
> > > В Fri, 3 Apr 2015 21:19:24 +0300
> > > Mantas Mikulėnas пишет:
> > >
> > > > Previously udev used to undo mounts when a device *disappeared;* when
> > > > systemd took over the task, it started unmounting things as soon as
> it
> > > > noticed that the device *doesn't exist right now.* While similar,
> the new
> > > > behavior can be annoying, since it also triggers if the device never
> > > > existed in the first place. For example:
> > > >
> > > > ~ My fstab has "/dev/mapper/luks-backups → /mnt/backup". I want to
> mount
> > > > another disk there (which has a different label), but even though
> `mount
> > > > /dev/sdb1 /mnt/backup` succeeds, the directory remains empty and
> won't
> > > show
> > > > up in `findmnt`.
> > > >
> > > > After a few retries I check dmesg and notice systemd saying that
> > > > "mnt-backup.mount is bound to an inactive device; stopping". Which
> means,
> > > > if my fstab says disk X is mounted there, systemd won't let me mount
> > > > anything else but disk X at that location.
> > > >
> > > > ~ I had to boot to emergency mode due to reasons, and attempted to
> mount
> > > > /boot & /boot/efi in order to fix something. Since my fstab had
> > > > "/dev/disk/by-partlabel/boot → /boot", any attempts to mount
> anything at
> > > > /boot get immediately undone – emergency mode has no udev, so I get
> > > > "boot.mount is bound to an inactive device; stopping" all over again.
> > > >
> > >
> > > Do these commits help?
> > >
> > > commit 628c89cc68ab96fce2de7ebba5933725d147aecc
> > > Author: Lennart Poettering
> > > Date: Fri Feb 27 21:55:08 2015 +0100
> > >
> > > core: rework device state logic
> > >
> > > commit 496068a8288084ab3ecf8b179a8403ecff1a6be8
> > > Author: Martin Pitt
> > > Date: Fri Mar 13 08:35:59 2015 +0100
> > >
> > > core: don't change removed devices to state "tentative"
> > >
> >
> > Nope, this is already on 093c2cfe3b1.
> >
> >
>
> I cannot reproduce it. Could you give more details (/etc/fstab line,
> systemctl status and systemctl show mnt-backup.mount before and after
> manual mount)?
>
Hmm, you're right, I cannot reproduce the /mnt/backup case either. Weird.
(I mostly remember it from 2 weeks ago.)
The /boot one though happened just yesterday:
--
Mantas Mikulėnas
# systemctl status boot.mount
● boot.mount - /boot
Loaded: loaded (/etc/fstab)
Active: inactive (dead) since Sat 2015-04-04 14:32:18 EEST; 47s ago
Where: /boot
What: /dev/disk/by-partlabel/boot
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 132 ExecUnmount=/bin/umount /boot -n (code=exited, status=0/SUCCESS)
# systemctl status /dev/disk/by-partlabel/boot
● dev-disk-by\x2dpartlabel-boot.device
Loaded: loaded
Active: inactive (dead)
# systemctl show boot.mount
Where=/boot
What=/dev/disk/by-partlabel/boot
Options=rw
Type=ext4
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
SloppyOptions=no
Result=success
ExecUnmount={ path=/bin/umount ; argv[]=/bin/umount /boot -n ; ignore_errors=no
; start_time=[Sat 2015-04-04 14:32:18 EEST] ; stop_time=[Sat 2015-04-04
14:32:18 EEST] ; pid=132 ; code=exited ; status=0 }
Slice=system.slice
MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615
Delegate=no
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=1885
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=1885
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=yes
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=boot.mount
Names=boot.mount
Requires=-.mount
RequiresOverridable=systemd-fsck@dev-disk-by\x5cx2dpartlabel-boot.service
Wants=system.slice
BindsTo=dev-disk-by\x5cx2dpartlabel-boot.device
RequiredBy=boot-efi.mount kernel-post-upgrade.path loc
Re: [systemd-devel] [PATCH] udev: input_id: tag accelerometers as ID_INPUT_ACCELEROMETER
Hi On Fri, Apr 3, 2015 at 8:55 PM, Hans de Goede wrote: [...] >> I don't think we should return when we see INPUT_PROP_ACCEL. If a >> keyboard embeds an accelerometer, we will miss it. I think I went too >> deep in detail for Wacoms/tablets devices and it confused you. Those >> don't need much processing in udev, we can mostly control everything >> out the tree. > > > Ok, I'll respin my patch to not have the return then. What's the plan? Use INPUT_PROP_ACCEL as "negative check" (necessary negative condition) for touchpads and mice? And as fallback hint for accelerometer if nothing else matched? I guess I'll see in v2 then. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] auto-unmount via BindsTo= is annoying
В Sat, 4 Apr 2015 13:44:50 +0300 Andrei Borzenkov пишет: > В Sat, 4 Apr 2015 12:55:34 +0300 > Mantas Mikulėnas пишет: > > > On Sat, Apr 4, 2015 at 7:37 AM, Andrei Borzenkov > > wrote: > > > > > В Fri, 3 Apr 2015 21:19:24 +0300 > > > Mantas Mikulėnas пишет: > > > > > > > Previously udev used to undo mounts when a device *disappeared;* when > > > > systemd took over the task, it started unmounting things as soon as it > > > > noticed that the device *doesn't exist right now.* While similar, the > > > > new > > > > behavior can be annoying, since it also triggers if the device never > > > > existed in the first place. For example: > > > > > > > > ~ My fstab has "/dev/mapper/luks-backups → /mnt/backup". I want to mount > > > > another disk there (which has a different label), but even though `mount > > > > /dev/sdb1 /mnt/backup` succeeds, the directory remains empty and won't > > > show > > > > up in `findmnt`. > > > > > > > > After a few retries I check dmesg and notice systemd saying that > > > > "mnt-backup.mount is bound to an inactive device; stopping". Which > > > > means, > > > > if my fstab says disk X is mounted there, systemd won't let me mount > > > > anything else but disk X at that location. > > > > > > > > ~ I had to boot to emergency mode due to reasons, and attempted to mount > > > > /boot & /boot/efi in order to fix something. Since my fstab had > > > > "/dev/disk/by-partlabel/boot → /boot", any attempts to mount anything at > > > > /boot get immediately undone – emergency mode has no udev, so I get > > > > "boot.mount is bound to an inactive device; stopping" all over again. > > > > > > > > > > Do these commits help? > > > > > > commit 628c89cc68ab96fce2de7ebba5933725d147aecc > > > Author: Lennart Poettering > > > Date: Fri Feb 27 21:55:08 2015 +0100 > > > > > > core: rework device state logic > > > > > > commit 496068a8288084ab3ecf8b179a8403ecff1a6be8 > > > Author: Martin Pitt > > > Date: Fri Mar 13 08:35:59 2015 +0100 > > > > > > core: don't change removed devices to state "tentative" > > > > > > > Nope, this is already on 093c2cfe3b1. > > > > > > I cannot reproduce it. Could you give more details (/etc/fstab line, > systemctl status and systemctl show mnt-backup.mount before and after > manual mount)? OK, I now see it in emergency mode as well. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd failing sporadically failing to bring up network device
Hi, I've noticed that networkd occasionally fails to bring up one of two network interfaces on boot (this happens about once every 70 or so boots). The machine in question is a VMware ESXi 5.5 guest with two VMXNET3 network adaptors. When this issue occurs the message rtnl: received address for a nonexistent link (1), ignoring is present in the journal. Does anyone know if this is a known issue in systemd 216 (I'm using Fedora 21)? I've attached a journal log below: (systemd-216-20.fc21.x86_64) Apr 03 11:15:47 h systemd[1]: Starting Login Service... Apr 03 11:15:47 h systemd[1]: Starting D-Bus System Message Bus... Apr 03 11:15:47 h systemd[1]: Started D-Bus System Message Bus. Apr 03 11:15:48 h chronyd[397]: chronyd version 1.31 starting Apr 03 11:15:48 h kernel: shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 Apr 03 11:15:48 h kernel: [drm] Initialized drm 1.1.0 20060810 Apr 03 11:15:48 h kernel: piix4_smbus :00:07.3: SMBus Host Controller not enabled! Apr 03 11:15:48 h kernel: parport_pc 00:05: reported by Plug and Play ACPI Apr 03 11:15:48 h kernel: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] Apr 03 11:15:48 h kernel: vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16 Apr 03 11:15:48 h kernel: vmw_vmci :00:07.7: Using capabilities 0xc Apr 03 11:15:48 h chronyd[397]: Frequency -2.442 +/- 94.425 ppm read from /var/lib/chrony/drift Apr 03 11:15:48 h kernel: vmw_vmci :00:07.7: irq 57 for MSI/MSI-X Apr 03 11:15:48 h kernel: vmw_vmci :00:07.7: irq 58 for MSI/MSI-X Apr 03 11:15:48 h kernel: Guest personality initialized and is active Apr 03 11:15:48 h kernel: VMCI host device registered (name=vmci, major=10, minor=58) Apr 03 11:15:48 h kernel: Initialized host personality Apr 03 11:15:48 h systemd-vconsole-setup[405]: /usr/bin/setfont failed with error code 1. Apr 03 11:15:48 h systemd-vconsole-setup[405]: /usr/bin/loadkeys failed with error code 1. Apr 03 11:15:48 h systemd[1]: Starting Network Service... Apr 03 11:15:48 h systemd[1]: Started NTP client/server. Apr 03 11:15:48 h systemd[1]: Found device /dev/ttyS0. Apr 03 11:15:48 h systemd-logind[387]: Watching system buttons on /dev/input/event0 (Power Button) Apr 03 11:15:48 h systemd-logind[387]: New seat seat0. Apr 03 11:15:48 h systemd[1]: Started Login Service. Apr 03 11:15:48 h kernel: alg: No test for crc32 (crc32-pclmul) Apr 03 11:15:48 h kernel: VMware vmxnet3 virtual NIC driver - version 1.2.1.0-k-NAPI Apr 03 11:15:48 h kernel: vmxnet3 :0b:00.0: # of Tx queues : 1, # of Rx queues : 1 Apr 03 11:15:48 h kernel: vmxnet3 :0b:00.0: irq 59 for MSI/MSI-X Apr 03 11:15:48 h kernel: vmxnet3 :0b:00.0: irq 60 for MSI/MSI-X Apr 03 11:15:48 h kernel: vmxnet3 :0b:00.0 eth0: NIC Link is Up 1 Mbps Apr 03 11:15:48 h kernel: ppdev: user-space parallel port driver Apr 03 11:15:48 h kernel: vmxnet3 :13:00.0: # of Tx queues : 1, # of Rx queues : 1 Apr 03 11:15:48 h systemd-networkd[422]: timestamp of '/etc/systemd/network' changed Apr 03 11:15:48 h kernel: vmxnet3 :13:00.0: irq 61 for MSI/MSI-X Apr 03 11:15:48 h kernel: vmxnet3 :13:00.0: irq 62 for MSI/MSI-X Apr 03 11:15:48 h kernel: vmxnet3 :13:00.0 eth1: NIC Link is Up 1 Mbps Apr 03 11:15:48 h kernel: [drm] DMA map mode: Using physical TTM page addresses. Apr 03 11:15:48 h kernel: [drm] Capabilities: Apr 03 11:15:48 h kernel: [drm] Rect copy. Apr 03 11:15:48 h kernel: [drm] Cursor. Apr 03 11:15:48 h kernel: [drm] Cursor bypass. Apr 03 11:15:48 h kernel: [drm] Cursor bypass 2. Apr 03 11:15:48 h kernel: [drm] 8bit emulation. Apr 03 11:15:48 h kernel: [drm] Alpha cursor. Apr 03 11:15:48 h kernel: [drm] Extended Fifo. Apr 03 11:15:48 h kernel: [drm] Multimon. Apr 03 11:15:48 h kernel: [drm] Pitchlock. Apr 03 11:15:48 h kernel: [drm] Irq mask. Apr 03 11:15:48 h kernel: [drm] Display Topology. Apr 03 11:15:48 h kernel: [drm] GMR. Apr 03 11:15:48 h kernel: [drm] Traces. Apr 03 11:15:48 h kernel: [drm] GMR2. Apr 03 11:15:48 h kernel: [drm] Screen Object 2. Apr 03 11:15:48 h kernel: [drm] Command Buffers. Apr 03 11:15:48 h kernel: [drm] Max GMR ids is 64 Apr 03 11:15:48 h kernel: [drm] Max number of GMR pages is 65536 Apr 03 11:15:48 h kernel: [drm] Max dedicated hypervisor surface memory is 163840 kiB Apr 03 11:15:48 h kernel: [drm] Maximum display memory size is 8192 kiB Apr 03 11:15:48 h kernel: [drm] VRAM at 0xec00 size is 8192 kiB Apr 03 11:15:48 h kernel: [drm] MMIO at 0xfe00 size is 256 kiB Apr 03 11:15:48 h kernel: [drm] global init. Apr 03 11:15:48 h kernel: [TTM] Zone kernel: Available graphics memory: 508754 kiB Apr 03 11:15:48 h kernel: [TTM] Initializing pool allocator Apr 03 11:15:48 h kernel: [TTM] Initializing DMA pool allocator Apr 03 11:15:48 h kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Apr 03 11:15:48 h kernel: [drm] No driver support for vblank timestamp query. Apr 03 11:15:48 h kernel: [drm] Screen objects system initialized Apr 03
Re: [systemd-devel] auto-unmount via BindsTo= is annoying
В Sat, 4 Apr 2015 12:55:34 +0300 Mantas Mikulėnas пишет: > On Sat, Apr 4, 2015 at 7:37 AM, Andrei Borzenkov > wrote: > > > В Fri, 3 Apr 2015 21:19:24 +0300 > > Mantas Mikulėnas пишет: > > > > > Previously udev used to undo mounts when a device *disappeared;* when > > > systemd took over the task, it started unmounting things as soon as it > > > noticed that the device *doesn't exist right now.* While similar, the new > > > behavior can be annoying, since it also triggers if the device never > > > existed in the first place. For example: > > > > > > ~ My fstab has "/dev/mapper/luks-backups → /mnt/backup". I want to mount > > > another disk there (which has a different label), but even though `mount > > > /dev/sdb1 /mnt/backup` succeeds, the directory remains empty and won't > > show > > > up in `findmnt`. > > > > > > After a few retries I check dmesg and notice systemd saying that > > > "mnt-backup.mount is bound to an inactive device; stopping". Which means, > > > if my fstab says disk X is mounted there, systemd won't let me mount > > > anything else but disk X at that location. > > > > > > ~ I had to boot to emergency mode due to reasons, and attempted to mount > > > /boot & /boot/efi in order to fix something. Since my fstab had > > > "/dev/disk/by-partlabel/boot → /boot", any attempts to mount anything at > > > /boot get immediately undone – emergency mode has no udev, so I get > > > "boot.mount is bound to an inactive device; stopping" all over again. > > > > > > > Do these commits help? > > > > commit 628c89cc68ab96fce2de7ebba5933725d147aecc > > Author: Lennart Poettering > > Date: Fri Feb 27 21:55:08 2015 +0100 > > > > core: rework device state logic > > > > commit 496068a8288084ab3ecf8b179a8403ecff1a6be8 > > Author: Martin Pitt > > Date: Fri Mar 13 08:35:59 2015 +0100 > > > > core: don't change removed devices to state "tentative" > > > > Nope, this is already on 093c2cfe3b1. > > I cannot reproduce it. Could you give more details (/etc/fstab line, systemctl status and systemctl show mnt-backup.mount before and after manual mount)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] auto-unmount via BindsTo= is annoying
On Sat, Apr 4, 2015 at 7:37 AM, Andrei Borzenkov wrote: > В Fri, 3 Apr 2015 21:19:24 +0300 > Mantas Mikulėnas пишет: > > > Previously udev used to undo mounts when a device *disappeared;* when > > systemd took over the task, it started unmounting things as soon as it > > noticed that the device *doesn't exist right now.* While similar, the new > > behavior can be annoying, since it also triggers if the device never > > existed in the first place. For example: > > > > ~ My fstab has "/dev/mapper/luks-backups → /mnt/backup". I want to mount > > another disk there (which has a different label), but even though `mount > > /dev/sdb1 /mnt/backup` succeeds, the directory remains empty and won't > show > > up in `findmnt`. > > > > After a few retries I check dmesg and notice systemd saying that > > "mnt-backup.mount is bound to an inactive device; stopping". Which means, > > if my fstab says disk X is mounted there, systemd won't let me mount > > anything else but disk X at that location. > > > > ~ I had to boot to emergency mode due to reasons, and attempted to mount > > /boot & /boot/efi in order to fix something. Since my fstab had > > "/dev/disk/by-partlabel/boot → /boot", any attempts to mount anything at > > /boot get immediately undone – emergency mode has no udev, so I get > > "boot.mount is bound to an inactive device; stopping" all over again. > > > > Do these commits help? > > commit 628c89cc68ab96fce2de7ebba5933725d147aecc > Author: Lennart Poettering > Date: Fri Feb 27 21:55:08 2015 +0100 > > core: rework device state logic > > commit 496068a8288084ab3ecf8b179a8403ecff1a6be8 > Author: Martin Pitt > Date: Fri Mar 13 08:35:59 2015 +0100 > > core: don't change removed devices to state "tentative" > Nope, this is already on 093c2cfe3b1. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug blocking service start?
Thanks for the reply Lennart! I'm sorry I couldn't attend your FOSSASIA talk in Singapore. I was on holiday. On Sat, 4 Apr 2015, at 12:16 AM, Lennart Poettering wrote: > something else that runs before it is hanging hence. What does > "systemctl list-jobs" say before you run this and it hangs? [root@rpi2 ~]# systemctl list-jobs JOB UNIT TYPE STATE 95 surf.service start waiting 97 systemd-networkd-wait-online.service start running 96 network-online.targetstart waiting 3 jobs listed. So, maybe the network-online target is not ever bring hit? I'm using systemd-networkd and I'm certainly online, so I am not sure where the problem lies. Any ideas? Here is the surf service file: http://ix.io/hiQ This is my systemctl http://ix.io/hiR Kind regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Service runs as imaps, but imaps can not read the journal
I have the following fetchMail.service file: [Unit] Description=Fetch email for the IMAPS server After=network.target [Service] Type=simple ExecStart=/home/imaps/bin/fetchMail.sh Restart=always User=imaps StandardError=journal [Install] WantedBy=multi-user.target But when I as imaps run: journalctl --since="2015-04-04 08:00" I do not see any log information. Would it not be logical that the user can see the log information of its own process? This is with systemd version 210. -- Cecil Westerhof ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
Lennart Poettering [2015-04-03 14:06 +0200]: > Well, it sounds really wrong btw, if NM shuts down the ifaces just > because it got kicked off the bus... That's massively wrong. It doesn't -- wpa_supplicant does. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
