[systemd-devel] Virtual tty
Hi, quick question: when doing systemctl -t device it shows all the plugged devices on my laptop. Most of them seem rational (network adapters, DVD drives, etc.) However, it also shows 269 tty devices. It this the way it's supposed to be, or I have some misconfiguration in my laptop? If the first, there is a way to disable most of the tty devices? If the second, where should I look to correct my system? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd and cgroup management (and libcgroup)
On Tue, Oct 18, 2011 at 04:45:59PM -0400, Vivek Goyal wrote: > Hi, Oops, got old addresses of dhaval and bablir. Fixing it. Please reply to this mail instead of previous one. Thanks Vivek > > We have talked a lot of about libcgroup and systemd in the past and when I > thought that debate is settled, here comes some more things to discuss. > > Previously libcg was doing cgroup management and now sytemd is taken over > a lot of it. > > - Creation of hierarchies. Taking control of hierarchies have taken away > part of the cgconfig functionality. > > - Providing automatic cgroups for users has taken away part of the > functionality provided by cgroup pam plugin. > > - Providing automatic cgroups for services has taken away the service > management which in the past potentially could be done with the help > of cgconfig. > > Now systemd is managing services and users from cgroup point of view > which past init system never did and that was part of the reason to > have pam_cgroup plugin and cgconfig. Given the fact that new init > system has taken over a lot of cgroup management, few things come > to mind. > > - Should systemd provide a way to change default cgroups of users as it > provides for services. > > - Should systemd provide a way to change default resources of cgroups of > users as it provides for services. > > - cgroup and associated resources now become properties of objects being > managed by systemd (services and users). To me it will make sense > to provide an API so that an application can call into those APIs > and manage it. > > Should systemd provide an API to manage cgroups and resources of cgroups > of services and users it is managing. > > Lennart, I know you had said that editing the unit file is an API, > but a real will API will help. > > Should cgconfig equivalent functionality be owned by systemd > --- > This is contentious one and I think there are two parts to it. > > - Is cgconfig really needed. What are the use cases given the fact that > systemd now takes care of setting up the system. > > - If cgconfig is needed, then who should really manage it. systemd or > libcg. > > I am finding it hard to think of any good use cases of cgconfig now given > the fact systemd has taken over service and user management. What else is > left out. Everything is children of either user sessions of services > and they should manage their own children cgroups. Where's the need > of statically defining cgroups and resources and what will be launched > in those. > > Even if there is, then it looks like systemd is better place to manage > it as it already is setting up the whole system and top level hierarchies. > Thanks to Jason for the suggestion. > > Any thougths on above issues are appreciated. > > Thanks > Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd and cgroup management (and libcgroup)
Hi, We have talked a lot of about libcgroup and systemd in the past and when I thought that debate is settled, here comes some more things to discuss. Previously libcg was doing cgroup management and now sytemd is taken over a lot of it. - Creation of hierarchies. Taking control of hierarchies have taken away part of the cgconfig functionality. - Providing automatic cgroups for users has taken away part of the functionality provided by cgroup pam plugin. - Providing automatic cgroups for services has taken away the service management which in the past potentially could be done with the help of cgconfig. Now systemd is managing services and users from cgroup point of view which past init system never did and that was part of the reason to have pam_cgroup plugin and cgconfig. Given the fact that new init system has taken over a lot of cgroup management, few things come to mind. - Should systemd provide a way to change default cgroups of users as it provides for services. - Should systemd provide a way to change default resources of cgroups of users as it provides for services. - cgroup and associated resources now become properties of objects being managed by systemd (services and users). To me it will make sense to provide an API so that an application can call into those APIs and manage it. Should systemd provide an API to manage cgroups and resources of cgroups of services and users it is managing. Lennart, I know you had said that editing the unit file is an API, but a real will API will help. Should cgconfig equivalent functionality be owned by systemd --- This is contentious one and I think there are two parts to it. - Is cgconfig really needed. What are the use cases given the fact that systemd now takes care of setting up the system. - If cgconfig is needed, then who should really manage it. systemd or libcg. I am finding it hard to think of any good use cases of cgconfig now given the fact systemd has taken over service and user management. What else is left out. Everything is children of either user sessions of services and they should manage their own children cgroups. Where's the need of statically defining cgroups and resources and what will be launched in those. Even if there is, then it looks like systemd is better place to manage it as it already is setting up the whole system and top level hierarchies. Thanks to Jason for the suggestion. Any thougths on above issues are appreciated. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-analyze blame lacks fsck info
Hi, Every now and them 'systemd-analyze time' reports that it booted in slightly under 3 minutes instead of the 5.6s I expect, but systemd-analyze blame shows only times in the 600ms range. Babysitting the boot shows that fsck is the culprit. Was excluding things like fsck-root a design decision for 'blame'? If not, any hints to get it included in the list? regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Makefile.am: reduce linked libraries
On 18.10.2011 13:14, Koen Kooi wrote: > > Op 18 okt. 2011, om 12:51 heeft har...@redhat.com het volgende geschreven: > >> From: Harald Hoyer >> >> For libselinux and libcap the --as-needed linker flag does not seem to >> work. In fact, it seems to be turned off completly, if one of these >> libraries is used after --as-needed. >> >> This patch reduces the amount of linked libraries. >> >> before: >> $ ldd /lib/systemd/systemd-timestamp >> linux-vdso.so.1 (0x7fffe95ff000) >> libselinux.so.1 => /lib64/libselinux.so.1 (0x00356d00) >> libcap.so.2 => /lib64/libcap.so.2 (0x00356d40) >> librt.so.1 => /lib64/librt.so.1 (0x00356cc0) >> libc.so.6 => /lib64/libc.so.6 (0x00356b40) >> /lib64/ld-linux-x86-64.so.2 (0x00356ac0) >> libdl.so.2 => /lib64/libdl.so.2 (0x00356bc0) >> libattr.so.1 => /lib64/libattr.so.1 (0x00357b00) >> libpthread.so.0 => /lib64/libpthread.so.0 (0x00356c00) >> >> after: >> $ ldd systemd-timestamp >> linux-vdso.so.1 (0x7fff4c333000) >> librt.so.1 => /lib64/librt.so.1 (0x00356cc0) >> libc.so.6 => /lib64/libc.so.6 (0x00356b40) >> /lib64/ld-linux-x86-64.so.2 (0x00356ac0) >> libpthread.so.0 => /lib64/libpthread.so.0 (0x00356c00) >> --- >> Makefile.am | 60 ++ >> 1 files changed, 39 insertions(+), 21 deletions(-) >> >> diff --git a/Makefile.am b/Makefile.am >> index dabe32a..76e5329 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> >> -$(CAP_LIBS) >> +$(CAP_LIBS) > > This replaces a tab with spaces and the rest of the patch is using a mixed > mode of tab and space as well. What's preferred in the systemd makefiles, > tabs or spaces? > > regards, > > Koen Makefile.am should be reformatted anyway, because it is already mixed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Makefile.am: reduce linked libraries
Op 18 okt. 2011, om 12:51 heeft har...@redhat.com het volgende geschreven: > From: Harald Hoyer > > For libselinux and libcap the --as-needed linker flag does not seem to > work. In fact, it seems to be turned off completly, if one of these > libraries is used after --as-needed. > > This patch reduces the amount of linked libraries. > > before: > $ ldd /lib/systemd/systemd-timestamp > linux-vdso.so.1 (0x7fffe95ff000) > libselinux.so.1 => /lib64/libselinux.so.1 (0x00356d00) > libcap.so.2 => /lib64/libcap.so.2 (0x00356d40) > librt.so.1 => /lib64/librt.so.1 (0x00356cc0) > libc.so.6 => /lib64/libc.so.6 (0x00356b40) > /lib64/ld-linux-x86-64.so.2 (0x00356ac0) > libdl.so.2 => /lib64/libdl.so.2 (0x00356bc0) > libattr.so.1 => /lib64/libattr.so.1 (0x00357b00) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00356c00) > > after: > $ ldd systemd-timestamp > linux-vdso.so.1 (0x7fff4c333000) > librt.so.1 => /lib64/librt.so.1 (0x00356cc0) > libc.so.6 => /lib64/libc.so.6 (0x00356b40) > /lib64/ld-linux-x86-64.so.2 (0x00356ac0) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00356c00) > --- > Makefile.am | 60 ++ > 1 files changed, 39 insertions(+), 21 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index dabe32a..76e5329 100644 > --- a/Makefile.am > +++ b/Makefile.am > > - $(CAP_LIBS) > +$(CAP_LIBS) This replaces a tab with spaces and the rest of the patch is using a mixed mode of tab and space as well. What's preferred in the systemd makefiles, tabs or spaces? regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Makefile.am: reduce linked libraries
From: Harald Hoyer For libselinux and libcap the --as-needed linker flag does not seem to work. In fact, it seems to be turned off completly, if one of these libraries is used after --as-needed. This patch reduces the amount of linked libraries. before: $ ldd /lib/systemd/systemd-timestamp linux-vdso.so.1 (0x7fffe95ff000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00356d00) libcap.so.2 => /lib64/libcap.so.2 (0x00356d40) librt.so.1 => /lib64/librt.so.1 (0x00356cc0) libc.so.6 => /lib64/libc.so.6 (0x00356b40) /lib64/ld-linux-x86-64.so.2 (0x00356ac0) libdl.so.2 => /lib64/libdl.so.2 (0x00356bc0) libattr.so.1 => /lib64/libattr.so.1 (0x00357b00) libpthread.so.0 => /lib64/libpthread.so.0 (0x00356c00) after: $ ldd systemd-timestamp linux-vdso.so.1 (0x7fff4c333000) librt.so.1 => /lib64/librt.so.1 (0x00356cc0) libc.so.6 => /lib64/libc.so.6 (0x00356b40) /lib64/ld-linux-x86-64.so.2 (0x00356ac0) libpthread.so.0 => /lib64/libpthread.so.0 (0x00356c00) --- Makefile.am | 60 ++ 1 files changed, 39 insertions(+), 21 deletions(-) diff --git a/Makefile.am b/Makefile.am index dabe32a..76e5329 100644 --- a/Makefile.am +++ b/Makefile.am @@ -631,10 +631,6 @@ libsystemd_basic_la_CFLAGS = \ $(AM_CFLAGS) \ $(SELINUX_CFLAGS) -libsystemd_basic_la_LIBADD = \ - $(SELINUX_LIBS) \ - $(CAP_LIBS) - libsystemd_core_la_SOURCES = \ src/unit.c \ src/job.c \ @@ -706,12 +702,13 @@ libsystemd_core_la_CFLAGS = \ libsystemd_core_la_LIBADD = \ libsystemd-basic.la \ + $(SELINUX_LIBS) \ $(DBUS_LIBS) \ $(UDEV_LIBS) \ $(LIBWRAP_LIBS) \ $(PAM_LIBS) \ $(AUDIT_LIBS) \ - $(CAP_LIBS) +$(CAP_LIBS) # This is needed because automake is buggy in how it generates the # rules for C programs, but not Vala programs. We therefore can't @@ -905,7 +902,8 @@ test_cgroup_CFLAGS = \ $(AM_CFLAGS) test_cgroup_LDADD = \ - libsystemd-basic.la + libsystemd-basic.la \ + $(SELINUX_LIBS) test_env_replace_SOURCES = \ src/test-env-replace.c @@ -934,7 +932,9 @@ test_login_CFLAGS = \ test_login_LDADD = \ libsystemd-basic.la \ -libsystemd-login.la +libsystemd-login.la \ +$(SELINUX_LIBS) \ +$(CAP_LIBS) test_install_SOURCES = \ src/test-install.c \ @@ -947,7 +947,8 @@ test_install_CFLAGS = \ $(DBUS_CFLAGS) test_install_LDADD = \ - libsystemd-basic.la + libsystemd-basic.la \ + $(SELINUX_LIBS) systemd_stdout_syslog_bridge_SOURCES = \ src/stdout-syslog-bridge.c \ @@ -993,7 +994,8 @@ systemd_random_seed_CFLAGS = \ $(AM_CFLAGS) systemd_random_seed_LDADD = \ - libsystemd-basic.la + libsystemd-basic.la \ + $(SELINUX_LIBS) systemd_shutdownd_SOURCES = \ src/utmp-wtmp.c \ @@ -1004,7 +1006,8 @@ systemd_shutdownd_CFLAGS = \ systemd_shutdownd_LDADD = \ libsystemd-basic.la \ - libsystemd-daemon.la + libsystemd-daemon.la \ + $(SELINUX_LIBS) systemd_hostnamed_SOURCES = \ src/hostnamed.c \ @@ -1032,7 +1035,8 @@ systemd_localed_CFLAGS = \ systemd_localed_LDADD = \ libsystemd-basic.la \ libsystemd-daemon.la \ - $(DBUS_LIBS) + $(DBUS_LIBS) \ + $(SELINUX_LIBS) dist_pkgdata_DATA = \ src/kbd-model-map @@ -1086,7 +1090,9 @@ systemd_logind_LDADD = \ libsystemd-daemon.la \ $(DBUS_LIBS) \ $(UDEV_LIBS) \ -$(ACL_LIBS) +$(ACL_LIBS) \ +$(CAP_LIBS) \ +$(SELINUX_LIBS) systemd_uaccess_SOURCES = \ src/uaccess.c @@ -1109,7 +1115,9 @@ systemd_uaccess_LDADD = \ libsystemd-daemon.la \ libsystemd-login.la \ $(UDEV_LIBS) \ -$(ACL_LIBS) +$(ACL_LIBS) \ +$(CAP_LIBS) \ +$(SELINUX_LIBS) systemd_shutdown_SOURCES = \ src/mount-setup.c \ @@ -1122,6 +1130,7 @@ systemd_shutdown_CFLAGS = \ systemd_shutdown_LDADD = \ libsystemd-basic.la \ + $(SELINUX_LIBS) \ $(UDEV_LIBS) systemd_modules_load_SOURCES = \ @@ -1140,7 +1149,8 @@ systemd_tmpfiles_CFLAGS = \ $(AM_CFLAGS) systemd_tmpfiles_LDADD = \ - libsystemd-basic.la + libsystemd-basic.la \ + $(SELINUX_LIBS) systemd_machine_id_setup_SOURCES = \ src/machine-id-setup.c \ @@ -1150,7 +1160,8 @@ systemd_machine_id_setup_CFLAGS = \ $(AM_CFLAGS) systemd_machine_id_setup_LDADD = \ - libsystemd-basic.la + libsystemd-basic.la \ + $(SELINUX_LIBS) systemd_sysctl_SOURCES = \ src/sysctl.c @@ -1234,7 +1245,8 @@ systemd_cryptsetup_CFLAGS = \ systemd_cryptsetup_LDADD = \ $(LIBCRYPTSETUP_LIBS) \ $(UDEV_LIBS) \ - libsystemd-basic.la + libsystemd-basic.la \ + $(SELINUX_LIBS) systemd_cryptsetu
Re: [systemd-devel] [PATCH] cryptsetup-generator: avoid ordering cycle on swap
Le lundi 17 octobre 2011 à 13:01 +0200, Tom Gundersen a écrit : > Devices with random keys (swap), should not be ordered before local-fs.target, > as this creates a cycle with systemd-load-random-seed.service (and also it > does not make sense, a swap device is not a local-fs). FYI, this patch was confirmed to fix issue reported on our bugzilla : https://bugzilla.novell.com/show_bug.cgi?id=721666 -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
