Re: [systemd-devel] about /run/cgmanager/fs
On Thu, Nov 19, 2015 at 7:09 PM, yan...@iscas.ac.cn <yan...@iscas.ac.cn> wrote: > > Hi guys! In my computer, there is no /run/cgmanager ,which configure file is > related? Thank you! cgmanager is not a part of systemd. I no longer recall if you can run cgmanager with systemd, but if you can the existence of cgmanager's files is related to cgmanager's configuration. Make sure it is installed, that the service is enabled, and that cgmanager is running correctly. Please contact the developers of cgmanager for further support, as this topic is not appropriate for this list. I believe the lxc-users list is where cgmanager support questions should be directed to. Best regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-sysctl: improvement in LXC containers
The sysctl service will not apply net rules when /proc/sys is ro but /proc/sys/net is rw. This occurs under LXC containers. Perhaps a secondary service which only runs for the net tree should be used with `ConditionPathIsReadWrite=/proc/sys/net/` and `ConditionPathIsReadWrite=!/proc/sys/`. The ExecStart would then be `/usr/lib/systemd/systemd-sysctl --prefix net`. Problem identified and worked around here: https://github.com/lxc/lxc/pull/683 Thank you, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service
On Mon, May 4, 2015 at 5:54 AM, Michael Biebl mbi...@gmail.com wrote: 2015-05-04 14:49 GMT+02:00 Michael Biebl mbi...@gmail.com: Since emergency.service has KillMode=process the running bash kept running, and the result was an unusable system. Btw, what's the reason for using KillMode=process in emergency.service? It seems to have been there since it was first introduced in 2010. $ git show 70fcff314feff469a8e61dbe5017ed74f5e0a09d -- units/emergency.service -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service
On Tue, May 5, 2015 at 4:47 PM, Cameron Norman camerontnor...@gmail.com wrote: On Mon, May 4, 2015 at 5:54 AM, Michael Biebl mbi...@gmail.com wrote: 2015-05-04 14:49 GMT+02:00 Michael Biebl mbi...@gmail.com: Since emergency.service has KillMode=process the running bash kept running, and the result was an unusable system. Btw, what's the reason for using KillMode=process in emergency.service? It seems to have been there since it was first introduced in 2010. $ git show 70fcff314feff469a8e61dbe5017ed74f5e0a09d -- units/emergency.service Crap I accidentally sent that. The commit: commit 70fcff314feff469a8e61dbe5017ed74f5e0a09d Author: Lennart Poettering lenn...@poettering.net Date: Tue Apr 13 05:18:12 2010 +0200 units: install a few basic units by default diff --git a/units/emergency.service b/units/emergency.service new file mode 100644 index 000..2e9d049 --- /dev/null +++ b/units/emergency.service @@ -0,0 +1,10 @@ +[Meta] +Description=Emergency Shell + +[Service] +ExecStart=/bin/sh +Type=simple +StandardInput=tty +Restart=restart-always +RestartSec=0 +KillMode=process If I had to take a guess I would say that it was desired to let the shell do its own process management, but Lennart can only know. Maybe KillMode=mixed would be better? Regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timers always run when time changes
On Thu, Apr 30, 2015 at 6:35 PM, Likang Wang labor...@gmail.com wrote: Hi all, The entire system is running on an embedded box, and the system time will be set to 2008-01-01 00:00:00 after every reboot. My app running on the box will get the real time from my server and update time on the box after every booting.(I could not use NTP or systemd-timesyncd for some other reason) Does the service file for this custom time syncing service have the directive `Before=time-sync.target` ? If it does, are you sure that when it is considered running by systemd that the time has indeed been synced? Cheers, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On Thu, Apr 16, 2015 at 9:43 AM, Tom Gundersen t...@jklm.no wrote: On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski l...@amacapital.net wrote: The ratio of complexity of capability code the kdbus folks have already written (hundreds of lines across multiple files) to its utility (very near zero AFAICT) is, in my book, not a good sign at all. We have several uses of this, see my mail to Jiri regarding CAP_SYS_BOOT for instance: https://lkml.org/lkml/2015/4/16/219 This could easily be done with polkit and a special `boot` group. Why does it need to use CAP_SYS_BOOT? I mean why would you even *want* CAP_SYS_BOOT to be used for this? Using CAP_SYS_BOOT means that anything you want to let cleanly shutdown the system you would also allow to do a hard shutdown and thus cause data loss in many cases. In summary: not **necessary** or **ideal** to use a capability in this case. If you could be so kind, could you summarize the other uses you have? And if you can, explain why using regular user/group credentials does not achieve the goal. Thank you, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, Apr 12, 2015 at 12:49 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 12.04.15 12:35, lynd...@your-mail.com (lynd...@your-mail.com) wrote: If interface:IP = eno1:192.168.1.1, then it's all good. But, if interface:IP = br0(attached to eno1):192.168.1.1, then there's a fail of sshd.service on boot. Hmm? why that? why does sshd care? What precisely fails? I mean, if the ip addres 192.168.1.1 is bound to a local interface, then sshd really should work, it shouldn't matter what kind of interface that is. It's probably just a race that you see with the bridge because the bridge is up at a later time than the ethernet device. -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
On Fri, Apr 10, 2015 at 5:17 AM, Tomasz Bursztyka tomasz.burszt...@linux.intel.com wrote: Hi, [snip] As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner. systemd-proxy-discoveryd will more or less implement the same ideas with improvements. It will get rid of big JS engines like spidermonkey or v8 which are overkill for the tiny PAC files to be executed on, for instance. From pacrunner experience, APIs will be also improved. This one is using - at least in this RFC - the duktape JS engine to run the PAC files. Note it is not provided in this patchset. Latest version 1.2.x was used. It seems that duktape is really not in a suitable shape to be packaged in distributions (https://github.com/svaarala/duktape/issues/94). Do you have any plans to get it into shape? Also, and I am just curious, what is the specific reasoning duktape is preferred? Smaller memory footprint? Thanks, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Set the NOCOW flag for the journal via tmpfiles
On Sun, Mar 29, 2015 at 12:43 PM, Goffredo Baroncelli kreij...@libero.it wrote: Hi, did you find the time to give a look a these patches ? Do you have any suggestions ? I do not know about anyone else, but this message was in my spam box. The reason was: It has a from address in libero.it but has failed libero.it's required tests for authentication. Best regards, -- Cameron Norman On 2015-03-21 12:56, Goffredo Baroncelli wrote: Hi all, these patches set reverts the commit 11689d2 journald: turn off COW for journal files on btrfs which enables *unconditionally* the NOCOW flag for the journal files. The reason was that the performances of the journal file format are very bad on btrfs, and decrease during the time. Disabling the COW behavior, the perfomances increase. Unfortunately disabling the COW behavior leads to disable the BTRFS checksums, which in turn prevents BTRFS to rebuild a corrupted file in a RAID filesystem [3]. To avoid that I proposed a patch which introduces a configurable option to disables the turn off COW behavior[1]. Lennart commented that instead he prefer to set the NOCOW attribute via tmpfile.d snippets. A further patches set was proposed and accepted [2] to extend systemd-tmpfiles to change the file attributes. This last patches set removes the turn off COW behavior (patch #1) and introduces a new tmpfiles.d snippet which enable the NOCOW beahvior for the journal files (patch #2). So a sysadmin can disable this setting overriding this file configuration. BR G.Baroncelli [1] Re: [systemd-devel] [RFC][PATCH] Add option to enable COW for journal file https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28724.html [2] https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg29313.html [3] http://en.wikipedia.org/wiki/Btrfs#Checksum_tree_and_scrubbing -- gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] activate on DBus signal
On Mon, Mar 23, 2015 at 1:54 AM, WaLyong Cho walyong@samsung.com wrote: Hi, Now, I'm looking for a method to a service be activated on special DBus signal. If a process is running for waiting some of DBus signal this can be useful. Obviously you want to use systemd, but you may want look at prior art in Upstart with the upstart-dbus-bridge: http://upstart.ubuntu.com/cookbook/#upstart-dbus-bridge I already told with Simon in DBus mailing list. see this thread: http://lists.freedesktop.org/archives/dbus/2015-March/016607.html Simon said: If it did, there are some nasty ordering constraints - I certainly wouldn't want to have to delay delivery of a broadcast until all interested services had started up! - so I don't think adding this feature would be a good idea. How about also support for DBus signal? My idea is... Add new configuration directory. (e.g. /etc/systemd/active-by-signal) And service can install its configuration file on there with below format. (Please don't care of its detail. It just a example.) I would think this fits better as a new unit type. These units would act just like socket, path, or timer units, in that they launch services (default of service of the same name) when an event occurs. Regardless of implementation, this is definitely a useful feature that I can see being used in a few situations already. For example, in elementary OS we use a NM dispatcher script to detect captive logins and autoprompt users, but this requires hacky setting of DISPLAY variables in that script. It would be cleaner if we could just launch a script when NM signals the connection coming. This would be a user/session service so there would be no need to manually set env variables like DISPLAY. Here is the script for reference: http://bazaar.launchpad.net/~elementary-apps/capnet-assist/trunk/view/head:/90captive_portal_test Cheers, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] is-enabled does not work
On Mar 20, 2015 1:56 PM, Cecil Westerhof cldwester...@gmail.com wrote: When executing on a Debian system: systemctl is-enabled atd.service I get: Failed to issue method call: No such file or directory On a openSUSE system it works without a hitch. What could be the reason it does not work on the Debian systems? IIRC debian uses at as the service name. -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Sun, Feb 22, 2015 at 4:52 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Feb 22, 2015 at 11:58:25PM +, Luke Kenneth Casson Leighton wrote: On Wed, Feb 18, 2015 at 9:10 AM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Luke, I am mostly a lurker on the systemd mailing list, so my opinion does not carry weight in this community. On Tue, Feb 17, 2015 at 9:24 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt I understood most of these dependencies to be indirect: Packages that depend on other packages that in turn depend on libsystemd. Is that correct? that's right. so, what that means is that the actual number of packages which would need to be converted to dynamic loading is actually very small (about 100), and the remaining 4,483 would be fine (not need any work done on them at all). On the other hand the library is tiny and basically falls back to being a no-op in the case where systemd is not PID1, so it does not hurt non-systemd systems to have this library in any way. ...except that its introduction (usually --with-libsystemd) in those 100 (or so) packages has been done in a mutually-exclusive, hard-compile-time switch that *excludes* the possibility of dynamic (runtime) decision-making. I think this is the crux of the matter. Please accept the fact that this compile time switch does not preclude runtime decision making at all. When not running under systemd, calls into libsystemd degrade into silent noops. So they only cost that is an extra unused 600kb library, which is completely insignificant. And when it is significant you are usually in situation where you are compiling your own packages and can remove the systemd compile time option. -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timesyncd: tighten unit file
On Tue, Jan 27, 2015 at 1:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote: I'm not sure. Shouldn't we then ship a SELinux policy file then? Would you be interested in AppArmor profile for timesyncd, I have one? Also, if a distro uses weird SELinux policies or setuid helpers at every possible opportunity, shouldn't they have some responsibility of fixing their setup? Well, SELinux policy is managed in a central selinux policy database that is shipped in one big RPM. My selinux-fu is not good enough to maintain the policy file in systemd, and i am not sure this even is generic enough to be able to ship the same selinux policy that works across all distros that do selinux. If Apparmor policies are standardized and stand-alone enough, and there's a clear way to install them, and you are willing to look after it, then yes, I'd merge a patch that adds apparmor profiles to systemd upstream. A good idea would be to set the apparmor profile(s) to warn-only mode for some period of time, and then let distros patch (this would be a one liner) that to be in enforce mode if they want to test it out. One possible issue is that AppArmor profiles are installed in /etc. Will that be a problem WRT the whole stateless system initiative, or is it an acceptable exception to the only comments in /etc rule? Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timesyncd: tighten unit file
On Tue, Jan 27, 2015 at 1:58 PM, Topi Miettinen toiwo...@gmail.com wrote:
Well, I'm no expert on AppArmor policies. This is what I have:
#include tunables/global
/lib/systemd/systemd-timesyncd {
I am not sure how that would be done, but this needs to handle
timesyncd being in /usr/lib/systemd as well as /lib.
Also, adding `flags=(complain)` just before the curly brace puts the
profile into complain mode by default.
#include abstractions/nameservice
capability setgid,
capability setuid,
capability sys_time,
capability setpcap,
/etc/ld.so.cache r,
/etc/systemd/timesyncd.conf r,
/lib/systemd/systemd-timesyncd mr,
/lib/x86_64-linux-gnu/libattr.so.* mr,
/lib/x86_64-linux-gnu/libc-*.so mr,
/lib/x86_64-linux-gnu/libcap.so.* mr,
/lib/x86_64-linux-gnu/libm-*.so mr,
/lib/x86_64-linux-gnu/libnsl-*.so mr,
/lib/x86_64-linux-gnu/libpthread-*.so mr,
/lib/x86_64-linux-gnu/libresolv-*.so mr,
Use the variable `@{multiarch}` in place of `x86...`. Also, it is
probably desirable to add `{,usr/}` between the / and lib in these
lines for distros like Arch that have made the /usr merge.
/proc/cmdline r,
/proc/sys/kernel/random/boot_id r,
@{PROC} rather than /proc, so `@{PROC/cmdline r,`.
/run/systemd/netif/state r,
I have seen compatibility for pre-/run distros (i.e. adding `{,var/}`
before the run but after the slash), but probably not relevant for a
systemd daemon.
/var/lib/systemd/clock w,
}
Then post to appar...@lists.ubuntu.com asking for a review.
Lennart: if you really want to test the profile, you just need to spin
up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install
and enable apparmor, which takes a short while).
Cheers,
--
Cameron Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
On Mon, Jan 26, 2015 at 6:08 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 23.01.15 19:35, Christian Seiler (christ...@iwakd.de) wrote: - I hope I didn't forget anything I spent quite some time to ensuer that systemd systems work out-of-the-box in container managers. Any container manager that implements this stuff http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ should just work out-of-the-box, without *any* modification of the system to boot. Indeed, it seems the only thing that LXC needs to do to meet systemd is add an lxc.ptys option and phase out lxc.ttys in favor of that. I have filed a bug on LXC here: https://github.com/lxc/lxc/issues/419 Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd link file not setting MTU
On Tue, Jan 20, 2015 at 4:40 PM, Tom Gundersen t...@jklm.no wrote: Hi Ian, Did you try to reboot? Note that .link files are applied by udev (so usually during early boot). You can override their settings from .network files in some cases (at least with current git you can). Out of curiosity and for future reference, is there any way to get udev to apply the link files without rebooting? E.g. possibly with a udevadm trigger command of some sort. Thank you, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions regarding dbus started via systemd --user
On Fri, Jan 9, 2015 at 2:18 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Cameron Norman wrote on 09/01/15 02:24: On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: On 8 January 2015 at 17:24, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 08/01/15 16:03, Dimitri John Ledkov wrote: * I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1 and log in at the getty. How do I communicate with X11 session things over D-Bus, perhaps to disconnect from Telepathy without losing messages? * The same, but I ssh in from another machine instead. Same question? On Ubuntu at the moment this looks in practice something like this: find UPSTART_SESSION_ID of your tty7 session, export that variable in your getty shell, then use initctl list-env (systemctl) to list environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use that to communicate with dbus. It would be easer if there was a variable like `$XDG_RUNTIME_SESSION_DIR`, which would point to `$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to attach to a currently running session, and you could easily visualize which sessions are running. In a systemd world, you already have loginctl to easily visualise which sessions are running. It will even tell you if they are text/tty, X11 or Wayland sessions, show you the processes running etc. etc. But using a SESSION_DIR like that breaks lots of other nice things, such as socket activation (unless you also run systemd --session instance which is certainly not planned!). In the user model, users will have their systemd --user daemon running and it can listen on all sorts of sockets in $XGD_RUNTIME_DIR for you and launch the actual services behind those sockets as needed. I apologize my comment was a little off topic because I was referring to setups like upstart --session, not systemd --user. Since upstart --session (or a theoretical, and likely to remain so, systemd --session) would be aware of that, it could perform socket activation correctly. It would also be nice because services that do not conflict with themselves when running a second instance with the same uid (not dconf, but something along the lines of a GUI shell or gnome-session/upstart) could use it instead of doing their own session instancing (like upstart does). While this could be attractive in some instances, I think it's ugly in others. Things are held together with env vars, or properties on the X11 root window/xsettings (or equiv) and I think it becomes quite messy. With things designed properly around the user model and a few API calls for those apps that need to worry about sessions, means that things are designed better from the ground up. But to be honest, this could easily be a bikeshed debate and that's not really why I started this thread :D Yeah I was suggesting simply making the session paradigm a little cleaner by holding it together with only one env var instead of multiple, not looking to discredit the user paradigm. Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions regarding dbus started via systemd --user
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: On 8 January 2015 at 17:24, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 08/01/15 16:03, Dimitri John Ledkov wrote: * I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1 and log in at the getty. How do I communicate with X11 session things over D-Bus, perhaps to disconnect from Telepathy without losing messages? * The same, but I ssh in from another machine instead. Same question? On Ubuntu at the moment this looks in practice something like this: find UPSTART_SESSION_ID of your tty7 session, export that variable in your getty shell, then use initctl list-env (systemctl) to list environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use that to communicate with dbus. It would be easer if there was a variable like `$XDG_RUNTIME_SESSION_DIR`, which would point to `$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to attach to a currently running session, and you could easily visualize which sessions are running. It would also be nice because services that do not conflict with themselves when running a second instance with the same uid (not dconf, but something along the lines of a GUI shell or gnome-session/upstart) could use it instead of doing their own session instancing (like upstart does). Cheers, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: print unit package in status
On Thu, Dec 18, 2014 at 8:35 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 18.12.2014 um 17:19 schrieb Spencer Baugh: Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32) On 12/18/2014 04:00 AM, Spencer Baugh wrote: When printing the status of a unit, open a connection to the session bus and query PackageKit for the package that the unit file belongs to. Print it if PackageKit knows. There are gazillion package manager in the wild PackageKit is a generic interface to the local package manager, used by all the major distros and desktop environments. It's installed by default on any normal desktop/laptop. So this is different from hardcoding a call out to yum or apt please when do so *silently* fall back to ignore it on systems where PackageKit is removed by intention, that's what frequently is done on machines of users deploy servers and their own workstations and operate exclusively with YUM or DNF in short: don't make it another log-flood candidate The patch takes that into account: /* we frequently can't get the user bus, nor call PackageKit, so don't complain on error */ -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cgroups-agent not working in containers
On Wed, Nov 26, 2014 at 1:29 PM, Richard Weinberger rich...@nod.at wrote: Hi! I run a Linux container setup with openSUSE 13.1/2 as guest distro. After some time containers slow down. An investigation showed that the containers slow down because a lot of stale user sessions slow down almost all systemd tools, mostly systemctl. loginctl reports many thousand sessions. All in state closing. This sounds similar to an issue that systemd-shim in Debian had. Martin Pitt (helps to maintain systemd in Debian) fixed that issue; he may have some ideas here. I CC'd him. The bug (at Martin's message with most relevant info) for reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756076#75 Best regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Put user@.service cgroups into all controllers (user LXC)
On Nov 3, 2014 8:21 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/03/2014 03:25 PM, Martin Pitt wrote: Hints are appreciated. Thanks! Assuming you have read [1] Is not the solution to this problem to simply drop systemd-shim and cgmanager and just use systemd? His message is how the behavior they are relying on in cgmgr is not what systemd gives, and how that is causing problems with unpriveleged LXC containers. So no, I do not think so. Regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Put user@.service cgroups into all controllers (user LXC)
On Mon, Nov 3, 2014 at 8:32 AM, Cameron Norman camerontnor...@gmail.com wrote: On Nov 3, 2014 8:21 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/03/2014 03:25 PM, Martin Pitt wrote: Hints are appreciated. Thanks! Assuming you have read [1] Is not the solution to this problem to simply drop systemd-shim and cgmanager and just use systemd? His message is how the behavior they are relying on in cgmgr is not what systemd gives, and how that is causing problems with unpriveleged LXC containers. So no, I do not think so. I apologize. I did not realize you meant swapping cgmanager for systemd in the guest; I thought you were referring to the host. Regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to use cgroups within containers?
On Fri, Oct 17, 2014 at 2:37 PM, Richard Weinberger richard.weinber...@gmail.com wrote: ...fixing LXC devel mailinglist... :-\ On Fri, Oct 17, 2014 at 11:35 PM, Richard Weinberger richard.weinber...@gmail.com wrote: Dear systemd and container folks, at Plumbers the question raised how to provide cgroups to a systemd that lives in a container (with user namespaces). Due to the GDL train strikes I had to leave very soon and had no chance to talk to you in person. Was a solution proposed? All I want to know is how to provide cgroups in a sane and secure way to systemd. :-) I am not at all an expert on systemd's cgroups, however I do know the basic design of cgmanager. cgmanager provides cgroups to containers via a cgproxy service that relays messages to the main cgmanager service. You can read more about it here: https://github.com/cgmanager/cgmanager/blob/master/README. Perhaps systemd can use a similar model. Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
El mié, 8 de oct 2014 a las 10:24 , Marcel Holtmann mar...@holtmann.org escribió: Hi Cameron, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. udev was indeed my first thought for ethtool, however how would the ethtool commands be hooked in on containers? Or is ethtool not relevant there? Thanks, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Wed, Oct 8, 2014 at 2:26 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.10.14 19:48, Cameron Norman (camerontnor...@gmail.com) wrote: On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). Thank you, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A way to better integrate rsyslog into systemd?
El vie, 3 de oct 2014 a las 10:55 , Aleksei Besogonov alex.besogo...@gmail.com escribió: With all the recent noise about systemd abusing its position with the way it takes over logging I’ve been thinking about a way to solve it. As far as I understand the following holds: - Systemd takes over /dev/log socket which is normally served by rsyslog (or other syslog daemon). - That’s really required to make journald-based logging transparent and coherent for most use-cases. However, it creates a problem for log-heavy applications, because of additional roundtrips between processes. So far I’ve heard people actually using LD_PRELOAD tricks to hack around applications opening the /dev/log file inside the syslog(2). As far as I understand, it’s also not really configurable - the '/dev/log’ string is hardcoded into various libcs (e.g.: http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent versions of rsyslog can directly read journald files. But that’s still suboptimal solution, because it introduces an unnecessary layer. Namespacing each daemon to provide its own /dev tree with custom /dev/log sockets is possible, but impractical. So I propose the following solution: 1) Add an option to systemd units to allow passing opened /dev/log sockets to rsyslog (using the usual SOL_SOCKET mechanism). This seems annoyingly roundabout. A more straightforward method would be to just have rsyslog listen on /dev/log. Obviously that is the original method, and journald changed it, and there are reasons for that. I am pretty sure one of the main selling points of journald is the extreme catch all nature: from syslog messages, to daemon stdout/in, to X.Org logs, etc. You can easily access those logs from one place and with one set of tools. If the authors wanted syslog messages to not be intercepted by journald, I do not think they would have had journald listen on /dev/log. Of course, I can not speak for them, it just seems reasonable that that is their feelings about. An alternate reason for how journald works is so that all syslogs do not have to re-implement the forwarding logic. 2) Add the corresponding functionality to rsyslog. It should listen on a special socket (perhaps /run/rsyslog/socket_server ?) and treat all the incoming sockets as if they were accepted from /dev/log. Well it already is supposed to listen on /run/systemd/journal/syslog like that is /dev/log; that is how the messages are forwarded. It would also solve the problems with rsyslog using its own SCM_CREDENTIALS lookups. Can it not simply recognize it is listening on /run/systemd/journal/syslog and skip any kind of extra steps? Or would that cause sec issues (e.g. easier to overflow the logs by faking the PID / user then writing to the private socket directly)? Cheers, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [question] networkd: Any support for hooks?
Hello, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? Thank you, [1] Debian's networking service, re-implemented a couple times elsewhere (busybox, and some other independent stuff) -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
El Wed, 11 de Jun 2014 a las 10:00 AM, Lennart Poettering lenn...@poettering.net escribió: Hi! http://www.freedesktop.org/software/systemd/systemd-214.tar.xz Here it is, version 214. Stuffed with great new features, improvements in all areas, 1 I would think that removing m from the documentation entirely would make it hard for people looking at old tmpfile configurations to understand what m does. Why not keep it in the docs, but clearly mark it as deprecated? Awesome release, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
El Sun, 8 de Jun 2014 a las 11:44 AM, Leonid Isaev lis...@umail.iu.edu escribió: Hi, On Sun, Jun 08, 2014 at 12:33:44PM +, Rusty Bird wrote: Date: Sun, 08 Jun 2014 12:33:44 + From: Rusty Bird rustyb...@openmailbox.org To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks Leonid Isaev: But by the time network.target is reached there are no listening services yet, are there? So, why would one need a firewall? Adding to Djalal's and Mantas's examples, the systemd host may also be a gateway with its firewall configured to forward only *some* packets. Rusty Thanks for an explanation, but this is exactly what I don't understand. But please note, that I agree with you that firewall must be enabled as early as possible during boot... If systemd itself is a server (you mean journald really, yes?), how can I protect the machine with yet another target? Why there is no way to tell systemd directly to start listening only after network.target is up? On a related note, what do you do about things like sshd.socket (or crap likecups.socket) which are not ordered against anything network-related? Because the firewall comes up before the network interfaces, no connection can possibly be created before the firewall is configured. The result is that even though systemd is listening on cups.socket or sshd.socket, once a remote connection is established, the firewall will already be configured. Hope that helps, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to Restrict device in systemd?
El Tue, 3 de Jun 2014 a las 11:18 PM, Mohit Agrawal moagr...@redhat.com escribió: Hi, I want to block the device through the systemd cgroup so I have created a below unit file [Unit] Description=mydevblock [Service] DeviceAllow=/dev/zero ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=40 Restart=always [Install] WantedBy=multi-user.target As per my understanding in this unit file I have allowed only /dev/zero device so dd command should not create the file_1 successfully it should give the error . I was under the impression that files that were not devices could be accessed just fine. If you had the output file as /dev/foo, then I would expect the command to fail, but this seems valid. Best regards, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
in particular that of a launcher idea on system to replace alternatives on
the
ExecStart= line of a systemd service unit file, alternative ideas are of
course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
a little while ago with nothing concrete being recommended but instead a
few
options being now archived as possibilities. I'm looking for a bit wider
review of the approaches and recomendations.
Some general background for non xen folks: old xen requires the launch of
a daemon which implements supports of the xenstore, which is the database
that xen uses for information about guests / dom0. There are two supported
daemons, xenstored (C version) and oxenstored (Ocaml version) but they do
the
same thing. Right now old init lets you override which one you pick through
an environment variable on /etc/{sysconfig,default}/xencommons, the script
will use the appropriate on there. Systemd doesn't let you use variables on
the ExecStart line of a service unit file so alternatives are required.
The reason I'm being very careful here this could set a precedent and at
least for the launcher idea it'd require the usage of getenv() and
execve(),
and secure alternatives for these (secure_getenv(), execve_nosecurity())
have either been merged or suggested before for Linux. The systemd
discussion
is only specific to Linux but if we have a launcher we could consider it
for
other supported OSes. All that said I'd like proper review of the security
implications of *all* strategies but obviously in particular the launcher
idea. I want to tread carefuly before setting precedents.
You can also just invoke a shell script from ExecStart=. I mean, we try
to deemphesize them in the boot process, but there's nothing wrong with
using shell, if you need to parse shell configuraiton fragments and just
want to execute on ot another program...
I tried this and it didn't work given that systemd expects sd_notify()
to be called from the parent process, in this case the shell script.
Just use exec before the daemon command. I am pretty certain it can be
just like this:
ExecStart=/bin/sh -c exec $XENSTORED
xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
works just fine.
Best,
--
Cameron
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
