Re: [systemd-devel] How to disable systemd multiseat feature?
Thanks for answer Mr. Lennart, I thought GDM is always active due to systemd, because in Wikipedia it is written in GNOME article that: "Since GNOME 3.2 multiseat support has been only available on systems using systemd." so I thought it is related to systemd, I don't want disable graphical login, I just want when someone do login with GDM, it (GDM) becomes idle. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] proper use of /run/{user/, }/systemd/private sockets
Hi all:
hope you guys are doing great!. So i have a few questions, hope this is the
best place for them.
I've been doing a lot of work with `sd-bus.h` (basically i've been trying
to bind it to other languages to then interact with systemd natively).
I've been reading the man pages/blog post/general docs, but mostly the src
code. and i stumble across
https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L598-L605
and saw that you can connect to systemd using the sockets, for root would
be `/run/systemd/private`, and for users something like
`/run/user//systemd/private` and this trigger lots of questions, that
i have not been able to answer, so here they are:
Question 1)
what would be the advantage of connecting through dbus instead of directly
through the socket?
the way i connect to systemd is with `sd_bus_open_system` but i can also do
```
sd_bus_new(&bus);
sd_bus_set_address(bus, "unix:path=/run/systemd/private");
sd_bus_start(bus);
```
why (or when) would one be better than the other?
question 2);
i also look that you can do the same with the user connections (and this is
mostly true when the --user flag is given, at least on systemd-run), and
you can connect to something like `/run/user//systemd/private`, where
`/run/user/` is $XDG_RUNTIME_DIR, and i guess this is really the best
form to connect to systemd as a user, but is there any difference between
using that socket or doing `sd_bus_open_user`. ?
question 3)
systemd source code is pretty clear, really easy to learn from, also
sd-bus.h is incredible helpful and easy to use.
But the docs is good, don't get me wrong, but it could definitely use more
love. for instance the usage of the sockets
`/run/{user/uid,}/systemd/private`, is not documented anywhere that i could
find. is this intentional?, is this because this is a implementation detail
that may change in the future?. if so, what would be the correct way to
connect to systemd's socket?
i was particularly surprise that the sockets' path are hardcoded in the
code.
if this parts have not just gotten into the docs, i would be more than
happy to submit the PR for the docs.
Thank you guys!
Alvaro Leiva
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Serial console issue.
There was an extra coma in the grub, which I removed now I'm getting an output, but still the same, all the output in one shot until : [ 1.773708] hid-generic 0003:03F0:0024.0002: input,hidraw1: USB HID v1.10 Keyboard [CHICONY HP Basic USB Keyboard] on usb-:00:14.0-4/input0 Then it goes slowly lines by lines from set hostname, then stuck. At this moment, I can't ping nor access it by ssh. [ 31.325083] systemd[1]: Set hostname to . # amtterm X amtterm: NONE -> CONNECT (connection to host) 16994 open amtterm: CONNECT -> INIT (redirection initialization) amtterm: INIT -> AUTH (session authentication) amtterm: AUTH -> INIT_SOL (serial-over-lan initialization) amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active) serial-over-lan redirection ok connected now, use ^] to escape The system is powered off. The system is powered on. Warning, SOL device is running in loopback mode. Text input may not be accepted SOL device is no longer running in loopback mode [0.481486] :00:16.3: ttyS1 at I/O 0x30e0 (irq = 17) is a 16550A [0.483817] Non-volatile memory driver v1.3 [0.485314] Linux agpgart interface v0.103 [0.516340] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16) [0.764496] crash memory driver: version 1.1 [0.765780] rdac: device handler registered [0.767143] hp_sw: device handler registered [0.768644] emc: device handler registered [0.769923] alua: device handler registered [0.771264] libphy: Fixed MDIO Bus: probed [0.772573] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.774926] ehci-pci: EHCI PCI platform driver [0.776424] ehci-pci :00:1d.0: EHCI Host Controller [0.778110] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 [0.780596] ehci-pci :00:1d.0: debug port 2 [0.785957] ehci-pci :00:1d.0: irq 23, io mem 0xaa03a000 [0.793287] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [0.795242] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [0.797405] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.77] usb usb1: Product: EHCI Host Controller [0.801523] usb usb1: Manufacturer: Linux 3.10.0-514.26.2.el7.x86_64 ehci_hcd [0.804560] usb usb1: SerialNumber: :00:1d.0 [0.806081] hub 1-0:1.0: USB hub found [0.807283] hub 1-0:1.0: 3 ports detected [0.808914] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [0.810876] ohci-pci: OHCI PCI platform driver [0.812299] uhci_hcd: USB Universal Host Controller Interface driver [0.814612] xhci_hcd :00:14.0: xHCI Host Controller [0.816298] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [0.820865] xhci_hcd :00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x9810 [0.823879] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [0.826027] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.828309] usb usb2: Product: xHCI Host Controller [0.829960] usb usb2: Manufacturer: Linux 3.10.0-514.26.2.el7.x86_64 xhci-hcd [0.832213] usb usb2: SerialNumber: :00:14.0 [0.833843] hub 2-0:1.0: USB hub found [0.835291] hub 2-0:1.0: 11 ports detected [0.838630] xhci_hcd :00:14.0: xHCI Host Controller [0.840319] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [0.842697] usb usb3: New USB device found, idVendor=1d6b, idProduct=0003 [0.845042] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.847317] usb usb3: Product: xHCI Host Controller [0.849125] usb usb3: Manufacturer: Linux 3.10.0-514.26.2.el7.x86_64 xhci-hcd [0.851383] usb usb3: SerialNumber: :00:14.0 [0.852870] hub 3-0:1.0: USB hub found [0.854291] hub 3-0:1.0: 4 ports detected [0.856500] usbcore: registered new interface driver usbserial [0.858626] usbcore: registered new interface driver usbserial_generic [0.860705] usbserial: USB Serial support registered for generic [0.862639] i8042: PNP: No PS/2 controller found. Probing ports directly. [0.868072] serio: i8042 KBD port at 0x60,0x64 irq 1 [0.869831] serio: i8042 AUX port at 0x60,0x64 irq 12 [0.871762] mousedev: PS/2 mouse device common for all mice [0.873896] rtc_cmos 00:03: RTC can wake from S4 [0.875477] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 [0.877444] rtc_cmos 00:03: alarms up to one month, y3k, 242 bytes nvram, hpet irqs [0.880039] Intel P-state driver initializing. [0.881800] cpuidle: using governor menu [0.883499] hidraw: raw HID events driver (C) Jiri Kosina [0.885443] usbcore: registered new interface driver usbhid [0.887209] usbhid: USB HID core driver [0.888721] drop_monitor: Initializing network drop monitor service [0.890863] TCP: cubic registered [0.891940] Initializing XFRM netlink socket [0.893354] NET: Registered protocol family 10 [0.895017] NET: Registered protocol fam
Re: [systemd-devel] How to disable systemd multiseat feature?
On Mo, 13.11.17 17:21, Farhad Mohammadi Majd (farhadbenya...@yahoo.com) wrote: > Hello, I have a old PC with Debian 9 and GNOME 3.22 installed on, I > don't need to multiseat feature, so I want to disable this feature to > reduce RAM and CPU usage, because GNOME Display Manager (GDM) is always > active. How to do that? I am sorry, I am not grokking your question. Are you sure you mean "multiseat"? Multiseat is a concept that only is relevant if you have actual multiseat hardware. And if you don't the basic building blocks in systemd are essentially free, they don't consume resources. If you want to disable graphical login, then that has nothing to do with multiseat. Usually something like "systemctl disable --now gdm" or so should do that. But then again, I don't really grok the question, so maybe that's not what you are looking for. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to disable systemd multiseat feature?
Hello, I have a old PC with Debian 9 and GNOME 3.22 installed on, I don't need to multiseat feature, so I want to disable this feature to reduce RAM and CPU usage, because GNOME Display Manager (GDM) is always active. How to do that? THANKS ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Serial console issue.
Hello, I rebuilt my machine just to make sure it's all clean, now the machine boot ok with console=ttyS1 on the kernel. But now I've got no output nor login prompt. Dmesg | grep tyy [0.00] console [tty0] enabled [0.464947] 00:01: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [0.485527] :00:16.3: ttyS1 at I/O 0x30e0 (irq = 17) is a 16550A Grub: RUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="serial console" GRUB_SERIAL_COMMAND="serial --speed=115200" GRUB_CMDLINE_LINUX="biosdevname=0 net.ifnames=0 rhgb rd.shell=0,console=ttyS1" GRUB_DISABLE_RECOVERY="true" GRUB_GFXMODE=text Output from amtterm for connecting to the machine ~ # amtterm hostname amtterm: NONE -> CONNECT (connection to host) 16994 open amtterm: CONNECT -> INIT (redirection initialization) amtterm: INIT -> AUTH (session authentication) amtterm: AUTH -> INIT_SOL (serial-over-lan initialization) amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active) serial-over-lan redirection ok connected now, use ^] to escape The system is powered off. The system is powered on. Warning, SOL device is running in loopback mode. Text input may not be accepted SOL device is no longer running in loopback mode Thanks. -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: 08 November 2017 13:56 To: Yann Le Mouel Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Serial console issue. On Di, 07.11.17 16:48, Yann Le Mouel (y...@lemouel.ch) wrote: > Hello, > > > > I've been following your guidelines (serial-console.html) about serial > console. I'm testing this function via AMT on Intel NUC'S on Centos > 7.4. I'm using AMTTERM package for the test. > > > > I managed to get the serial working until certain point, as below, I > can see the boot which is really fast until set hostname, and then so > slow, lines by lines, Normally, it should suffice to set the kernel console to ttyS0 (or whichever device you use) via the kernel cmdline. The rest should then happen fully automatically, as systemd contains an automatic genreator which uses this to also invoke a serial getty on the same serial port you used for the console. Note that if multiple processes fight for console ownership you will experience all kinds of problems. The log you pasted shows that you have getty@.service and serial-getty@.service fighting for access to ttyS1. That's already indication of a problem, and most likely happened because you enabled these units manually? First of all, that should not be necessary, as things should work automatically anyway, as mentioned above. Moreover, enable "getty@.service" (as opposed to serial-getty@.service) is incorrect anyway, as that unit is for VTs only, not for serial ttys. Hence, I am not entirely sure what changes you made. My recommendation would be to undo them all, and just set console= on the kernel cmdline, and all should be good. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] MemoryLimit for user unit
On So, 12.11.17 18:14, Stefan Schweter (ste...@schweter.it) wrote: > Hi systemd-users, > > I tried to add a memory limit for a user service unit (inspired by [1]), > it looks like: > > [Service] > # > MemoryAccounting=true > MemoryLimit=1G > > Now the problem is that the (user) service consumes more than 1G without > being terminated. Note that on cgroupsv1 delegation of controllers to unprivileged code is not safe and hence systemd won't do it. That means you have to boot in cgroupsv2 mode (i.e. "unified") to get any controller support at all for the user systemd instance. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How does hybrid cgroup setup work?
On So, 12.11.17 20:17, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > > And then there's also the big issue: the cgroup code is complex enough > > given that we need to support three different setups. I'd really > > prefer if we'd not add even more to that. In fact, I am really looking > > forward for the day we can drop all cgroup support besides the unified > > one from our tree. We could delete *so much* code then! And there's > > only one thing hackers prefer over writing code: deleting code... ;-) > > I guess that day will come when all the controllers move to v2. What > is your knowledge regarding plans of moving all the control groups? > Are they all going to be moved? If so, are they all going to provide > somehow similar functionality? For example I have noticed I cannot > find a similar functionality of "memory.max_usage_in_bytes" in v2 > memory control group. I am not sure if everyone will be happily jump > to #2 (unified) way any time soon or if they will still want to use > some parts from v1 in an unified fashion meanwhile. As I understood Tejun the major controllers will all be moved, but some some will be dropped entirely, for example the "devices" one (since what it does is not precisely resource management but access management, and it is mostly redundant as seccomp + picking carefully how /dev is put together has the same effect. the memory controller should be fully moved over already. systemd's MemoryMax= should do the right thing already. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
