Re: [systemd-devel] vt220 default for serial console still relevant?
Dear all, I've just read the discussion with a great interest. What I would like to add is that there a people (like me) who use real world serial consoles (not emulated as in qemu) for working with ARM single board computers. I usually use 'screen' terminal emulator to connect to /dev/ttyUSB0 or so. `screen' itself is running in Konsole (which is TERM=xterm). As far as I understand, 'screen' currently understands some set of vt2xx commands (coming from rs232 console) and converts them to render in xterm somehow. But I am not sure if it will still work correctly for other kind of term. 11.07.2020 19:51, Daan De Meyer пишет: > Hi, > > I was playing around with mkosi's qemu support, more specifically adding > the -nographic option to have the virtual machine output in my terminal > instead of a separate window. After figuring out that I had to add > console=ttyS0 to mkosi's kernel command line, I got the output from the vm > in my terminal as expected. However, because systemd defaults to TERM=vt220 > for serial consoles, the output is not colorized. I searched around a bit > and found that this is done for compatibility reasons. Will there ever be a > point where we can switch the default to something that supports colors > (like TERM=linux)? > > I managed to get around the problem by overriding serial-getty@ttyS0 and > setting Environment=TERM=linux explicitly but it's a bit of a pain and has > to be added to every rootfs that wants to support colored output on its > serial console. > > Cheers, > > Daan > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] reboot on emergency.target
вт, 7 апр. 2020 г. в 14:09, Lennart Poettering : > > On Di, 07.04.20 11:26, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > > > Hi, > > > > I would like my system to reboot (with some cool down timeout) on > > emergency.target instead of running the emergency shell. What would be > > the recommended way to achieve this behavior? Is it ok just to override > > default emergency.service to whatever I want? > > Just override emergency.service in /etc/systemd/system/ with a service > of your own, that sleeps and then issues "systemctl reboot". > > You could also just mask the service and pull in a different service > instead. Or you could mask it + pull in reboot.target as a dependency > from emergency.target via a .wants/ symlink (but then you woudln't get > your cool down timout). Thank you for the explanation. However, when I mask emergency.service and add-wants reboot.target, then emergency.target cannot be isolated anymore: # systemctl isolate emergency.target Failed to start emergency.target: Unit emergency.service is masked. > > Lennart > > -- > Lennart Poettering, Berlin -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] reboot on emergency.target
Hi, I would like my system to reboot (with some cool down timeout) on emergency.target instead of running the emergency shell. What would be the recommended way to achieve this behavior? Is it ok just to override default emergency.service to whatever I want? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
вт, 28 янв. 2020 г. в 15:25, Lennart Poettering : > > On Di, 28.01.20 15:07, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > > > Thanks for reply! I've just wanted to let you know about this issue > > after spending couple hours trying to understand why my container > > works on the one host and don't work on another one. > > I think there are couple things which can be done here. First, it > > would be great to modify the comment as proposed in PR 8200. If I knew > > that this test is fuzzy, I would not write this mail. > > Second, I didn't know about $container env until I read systemd > > sources. There are a lot of fragmental information about running > > systemd in docker in Internet, it would be great to have official > > systemd-point-of-view on this topic. > > We document the requirements and expectations to run systemd in > containers very explicitly here: > > https://systemd.io/CONTAINER_INTERFACE If I could google this page, it would save lot of my time. Thanks a lot! > > The intention of that documentation is of course that container > managers can make systemd payloads just work. To my knowledge most > container managers implemented the bits necessary for that, but Docker > people are not interested in this. There's little we can do about > that. > > I am sorry you picked the one container implementation who's not > interested in playing with the others, but there's nothing much we can > do about that. > > Lennart > > -- > Lennart Poettering, Berlin -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
вт, 28 янв. 2020 г. в 11:36, Lennart Poettering :
>
> On So, 26.01.20 11:55, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:
>
> > Hello,
> >
> > I've just found that an assumption used inside detect_container() is
> > not always true, and that leads to virtualization misdetection.
> > Namely, I am running systemd inside docker (19.03.5) container on
> > ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
> >
> > /* Interestingly /proc/1/sched actually shows the host's PID
> > for what we see as PID 1. If the PID
> > * shown there is not 1, we know we are in a PID namespace and
> > hence a container. */
> > check_sched:
> > r = read_one_line_file("/proc/1/sched", );
> >
> > However, I see the following when reading this file in the container:
> >
> > 64813fe8f025:/ # cat /proc/1/sched
> > bash (1, #threads: 1)
>
> Yes, this is known, and to our knowledge not really fixable, as
> there's no nice way to detect containers entirely generically these
> days (or more specifically: detect whether we are in a pidns that is
> not the main one).
>
> Also see:
>
> https://github.com/systemd/systemd/pull/8200
>
> > Unfortunately, this leads to virtualization misdetection on systemd
> > startup (docker host runs inside kvm):
>
> So, docker is the only container engine to my knowledge that refuses
> to play nice by default and is thus unwilling to implement the
> $container env var by default. To make the container env detectable
> you hence have to set the env var manually in your containers.
>
> Sorry for that, but there's nothing we can do about this. The kernel took
> the only somewhat generic mechanism to detect containers away from us
> and the Docker people aren't willing to make their stuff detectable,
> hence there's nothing we can do.
>
Hi,
Thanks for reply! I've just wanted to let you know about this issue
after spending couple hours trying to understand why my container
works on the one host and don't work on another one.
I think there are couple things which can be done here. First, it
would be great to modify the comment as proposed in PR 8200. If I knew
that this test is fuzzy, I would not write this mail.
Second, I didn't know about $container env until I read systemd
sources. There are a lot of fragmental information about running
systemd in docker in Internet, it would be great to have official
systemd-point-of-view on this topic.
> Lennart
>
> --
> Lennart Poettering, Berlin
--
With best regards,
Matwey V. Kornilov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] detect_container() for recent(?) docker
Hello,
I've just found that an assumption used inside detect_container() is
not always true, and that leads to virtualization misdetection.
Namely, I am running systemd inside docker (19.03.5) container on
ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
/* Interestingly /proc/1/sched actually shows the host's PID
for what we see as PID 1. If the PID
* shown there is not 1, we know we are in a PID namespace and
hence a container. */
check_sched:
r = read_one_line_file("/proc/1/sched", );
However, I see the following when reading this file in the container:
64813fe8f025:/ # cat /proc/1/sched
bash (1, #threads: 1)
---
Unfortunately, this leads to virtualization misdetection on systemd
startup (docker host runs inside kvm):
Detected virtualization kvm.
And that leads to the issues with getty-generator which tries to use
host serial tty devices.
Running the same docker container with "-e container=docker"
explicitly resolves both issues.
--
With best regards,
Matwey V. Kornilov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to apply ACLs: Invalid argument
2017-07-20 11:05 GMT+03:00 Lennart Poettering <lenn...@poettering.net>: > On Thu, 20.07.17 10:45, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > >> > I suspect 21d6220fe0bf24fda7df9833961e022cafa439bc will fix my issue. >> > I will check tomorrow. >> >> I've just found that >> >> sd_device_new_from_subsystem_sysname returns -22 for parport_pc >> device, because subsys variable has no ':' and driver == NULL which >> leads to -EINVAL in systemd v228. > > And did 21d6220fe0bf24fda7df9833961e022cafa439bc fix the issue for > you? Is this still a problem on more current versions? Yes, it helped. Seemingly, this needs to be backported to openSUSE's v228. > > Lennart > > -- > Lennart Poettering, Red Hat -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to apply ACLs: Invalid argument
2017-07-19 15:12 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: > 2017-07-19 13:32 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: >> 2017-07-19 13:10 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: >>> 2017-07-19 12:47 GMT+03:00 Lennart Poettering <lenn...@poettering.net>: >>>> On Wed, 19.07.17 12:38, Matwey V. Kornilov (matwey.korni...@gmail.com) >>>> wrote: >>>> >>>>> This is all that is relevant to Invalid Argument errno in strace: >>>>> >>>> [...] >>>>> readlinkat(AT_FDCWD, "/sys/module/parport", 0x55d7a4d5d940, 99) = -1 >>>>> EINVAL (Invalid argument) >>>> >>>> realinkat() returns EINVAL when invoked on a non-symlinks. It's not a >>>> real error, just a way to report that mismatch. >>>> >>>>> drwxr-xr-x 3 root root 0 июл 19 12:35 >>>>> /sys/devices/virtual/input/input7/event7 >>>>> drwxr-xr-x 5 root root 0 июл 19 12:31 /sys/module/parport >>>>> drwxr-xr-x 7 root root 0 июл 19 12:33 /sys/module/parport_pc >>>>> >>>>> It is brand-new openSUSE 42.2 installation. No selinux or something like >>>>> that. >>>> >>>> Not sure what else I can suggest then, except attaching gdb to logind >>>> and check what happens when you switch VTs... it should be sufficient >>>> to set a breakpoint onto devnode_acl_all() and wait until it gets >>>> triggered, and then follow the code until you see EINVAL thrown. >>>> >>>> Unless you know gdb well enough you shouldn't attempt that though... >>>> >>> >>> Ok, it is udev_enumerate_scan_devices who returns -22 >> >> Now I see that something wrong happens inside >> >> enumerator_scan_devices_children >> >> at >> >> sd_device_get_syspath >> > > k = sd_device_new_from_device_id(, dent->d_name); > > inside enumerator_scan_devices_tag() returns -22 for some entry. I suspect 21d6220fe0bf24fda7df9833961e022cafa439bc will fix my issue. I will check tomorrow. > >> >>> >>>> Lennart >>>> >>>> -- >>>> Lennart Poettering, Red Hat >>> >>> >>> >>> -- >>> With best regards, >>> Matwey V. Kornilov >> >> >> >> -- >> With best regards, >> Matwey V. Kornilov > > > > -- > With best regards, > Matwey V. Kornilov -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to apply ACLs: Invalid argument
2017-07-19 13:32 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: > 2017-07-19 13:10 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: >> 2017-07-19 12:47 GMT+03:00 Lennart Poettering <lenn...@poettering.net>: >>> On Wed, 19.07.17 12:38, Matwey V. Kornilov (matwey.korni...@gmail.com) >>> wrote: >>> >>>> This is all that is relevant to Invalid Argument errno in strace: >>>> >>> [...] >>>> readlinkat(AT_FDCWD, "/sys/module/parport", 0x55d7a4d5d940, 99) = -1 >>>> EINVAL (Invalid argument) >>> >>> realinkat() returns EINVAL when invoked on a non-symlinks. It's not a >>> real error, just a way to report that mismatch. >>> >>>> drwxr-xr-x 3 root root 0 июл 19 12:35 >>>> /sys/devices/virtual/input/input7/event7 >>>> drwxr-xr-x 5 root root 0 июл 19 12:31 /sys/module/parport >>>> drwxr-xr-x 7 root root 0 июл 19 12:33 /sys/module/parport_pc >>>> >>>> It is brand-new openSUSE 42.2 installation. No selinux or something like >>>> that. >>> >>> Not sure what else I can suggest then, except attaching gdb to logind >>> and check what happens when you switch VTs... it should be sufficient >>> to set a breakpoint onto devnode_acl_all() and wait until it gets >>> triggered, and then follow the code until you see EINVAL thrown. >>> >>> Unless you know gdb well enough you shouldn't attempt that though... >>> >> >> Ok, it is udev_enumerate_scan_devices who returns -22 > > Now I see that something wrong happens inside > > enumerator_scan_devices_children > > at > > sd_device_get_syspath > k = sd_device_new_from_device_id(, dent->d_name); inside enumerator_scan_devices_tag() returns -22 for some entry. > >> >>> Lennart >>> >>> -- >>> Lennart Poettering, Red Hat >> >> >> >> -- >> With best regards, >> Matwey V. Kornilov > > > > -- > With best regards, > Matwey V. Kornilov -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to apply ACLs: Invalid argument
2017-07-19 13:10 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: > 2017-07-19 12:47 GMT+03:00 Lennart Poettering <lenn...@poettering.net>: >> On Wed, 19.07.17 12:38, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: >> >>> This is all that is relevant to Invalid Argument errno in strace: >>> >> [...] >>> readlinkat(AT_FDCWD, "/sys/module/parport", 0x55d7a4d5d940, 99) = -1 >>> EINVAL (Invalid argument) >> >> realinkat() returns EINVAL when invoked on a non-symlinks. It's not a >> real error, just a way to report that mismatch. >> >>> drwxr-xr-x 3 root root 0 июл 19 12:35 >>> /sys/devices/virtual/input/input7/event7 >>> drwxr-xr-x 5 root root 0 июл 19 12:31 /sys/module/parport >>> drwxr-xr-x 7 root root 0 июл 19 12:33 /sys/module/parport_pc >>> >>> It is brand-new openSUSE 42.2 installation. No selinux or something like >>> that. >> >> Not sure what else I can suggest then, except attaching gdb to logind >> and check what happens when you switch VTs... it should be sufficient >> to set a breakpoint onto devnode_acl_all() and wait until it gets >> triggered, and then follow the code until you see EINVAL thrown. >> >> Unless you know gdb well enough you shouldn't attempt that though... >> > > Ok, it is udev_enumerate_scan_devices who returns -22 Now I see that something wrong happens inside enumerator_scan_devices_children at sd_device_get_syspath > >> Lennart >> >> -- >> Lennart Poettering, Red Hat > > > > -- > With best regards, > Matwey V. Kornilov -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to apply ACLs: Invalid argument
2017-07-19 12:47 GMT+03:00 Lennart Poettering <lenn...@poettering.net>: > On Wed, 19.07.17 12:38, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > >> This is all that is relevant to Invalid Argument errno in strace: >> > [...] >> readlinkat(AT_FDCWD, "/sys/module/parport", 0x55d7a4d5d940, 99) = -1 >> EINVAL (Invalid argument) > > realinkat() returns EINVAL when invoked on a non-symlinks. It's not a > real error, just a way to report that mismatch. > >> drwxr-xr-x 3 root root 0 июл 19 12:35 >> /sys/devices/virtual/input/input7/event7 >> drwxr-xr-x 5 root root 0 июл 19 12:31 /sys/module/parport >> drwxr-xr-x 7 root root 0 июл 19 12:33 /sys/module/parport_pc >> >> It is brand-new openSUSE 42.2 installation. No selinux or something like >> that. > > Not sure what else I can suggest then, except attaching gdb to logind > and check what happens when you switch VTs... it should be sufficient > to set a breakpoint onto devnode_acl_all() and wait until it gets > triggered, and then follow the code until you see EINVAL thrown. > > Unless you know gdb well enough you shouldn't attempt that though... > Ok, it is udev_enumerate_scan_devices who returns -22 > Lennart > > -- > Lennart Poettering, Red Hat -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Failed to apply ACLs: Invalid argument
Hello, I am running systemd 228. And one one particular system installation there are messages 'Failed to apply ACLs: Invalid argument' from systemd-logind. Moreover, ACL on /dev/dri/* are not set correctly after user log in. How could I figure out which argument is invalid? Managing ACLs on /dev filesystem using setfacl works fine. I've tried using debug log_level, but nothing helpful here: июл 18 16:21:00 photon systemd-logind[12814]: Got message type=method_call sender=:1.59 destination=org.freedesktop.login1 obj ect=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CreateSession cookie=2 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object =/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetConnectionUnixUser cookie=108 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.53 obj ect=n/a interface=n/a member=n/a cookie=33 reply_cookie=108 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/logi n1/seat/seat0 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=109 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartTransientUnit cookie=110 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Got message type=method_return sender=:1.0 destination=:1.53 object=n/a interface=n/a member=n/a cookie=2075 reply_cookie=110 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: New session 6 of user matwey. июл 18 16:21:00 photon systemd-logind[12814]: VT changed to 7 июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1/session/_35 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=111 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Failed to apply ACLs: Invalid argument июл 18 16:21:00 photon systemd-logind[12814]: Electing new display for user matwey июл 18 16:21:00 photon systemd-logind[12814]: Choosing session 6 in preference to 4 июл 18 16:21:00 photon systemd-logind[12814]: Ignoring session 2 июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=SessionNew cookie=112 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1/user/_1001 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=113 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1/seat/seat0 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=114 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Got message type=signal sender=:1.0 destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=2078 reply_cookie=0 error=n/a июл 18 16:21:00 photon systemd-logind[12814]: Sending reply about created session: id=6 object_path=/org/freedesktop/login1/session/_36 uid=1001 runtime_path=/run/user/1001 session_fd=22 seat=seat0 vtnr=7 июл 18 16:21:00 photon systemd-logind[12814]: Sent message type=method_return sender=n/a destination=:1.59 object=n/a interface=n/a member=n/a cookie=115 reply_cookie=2 error=n/a -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
