[systemd-devel] Orchestrating a shutdown immediately after boot
I'd like my system to: 1. boot 2. run a command 3. shut down I've implemented step 2 in a .service file [1], but I can't figure out how to automatically shut the system down once it's finished. shutdown.target conflicts with all services that don't set DefaultDependencies=false (which is most of them), so it seems I'm out of luck—there is no way to specify a target that requires both multi-user.target and shutdown.target. Is there some way to handle this situation? N.B. This is all running in an LXC; the overarching goal is to sandbox the command so it can't affect the rest of the system. - Kerrick [1] If it's useful, the .service file is as follows: [Unit] Description=Sandboxed Checkerbox command After=multi-user.target [Service] User=user Type=simple ExecStart=/bin/sh -c '/home/user/cmd /home/user/stdin /home/user/stdout 2/home/user/stderr' [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] static-nodes: move creation of static nodes from udevd to tmpfiles
On Sun, Jul 7, 2013 at 11:17 PM, Tom Gundersen t...@jklm.no wrote: Hi Umut, On Sun, Jul 7, 2013 at 8:11 PM, Umut Tezduyar u...@tezduyar.com wrote: Just a suggestion, can kmod-static-nodes.service be merged to systemd-static-nodes.service and have 2 ExecStartPre= as: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d ExecStartPre=/usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Could do, but what would be the benefit? I have no strong objection, except that in principle they are independent. Hi. I thought they serve for the same purpose. One generates device node information, other one creates the devices. I have no objection either but I thought we have documentation etc ready for systemd-static-nodes.service. If you are keeping kmod-static-nodes.service, maybe we should consider the configure flag for tmpfile support. If tmpfile support is not enabled, generated device file means nothing, I guess.. Thanks. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] X fatal server error with -seat option
Because multiseat doesn't work out-of-the-box with the Nvidia drivers I
try to figure out why.
The story so far:
create a udev rule for the nvidia device and attach it together with a
usb-hub to seat1
# loginctl seat-status seat1
seat1
Devices:
├─/sys/devices/pci:00/:00:05.0/:02:00.0
│ [MASTER] pci::02:00.0
├─/sys/devices/pci:00/:00:05.0/:02:00.1/sound/card2
│ sound:card2 NVidia
│
├─/sys/devices/pci:00/:00:05.0/:02:00.1/sound/card2/input17
│ │ input:input17 HDA NVidia HDMI/DP,pcm=7
│
└─/sys/devices/pci:00/:00:05.0/:02:00.1/sound/card2/input18
│ input:input18 HDA NVidia HDMI/DP,pcm=3
├─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.3
│ usb:1-1.3
│
└─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input2
│ input:input2 Cypress Sem PS2/USB Browser Combo
Mouse
└─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4
usb:1-1.4
├─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input3
│ input:input3 BTC USB Multimedia Keyboard
└─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.1/input/input4
input:input4 BTC USB Multimedia Keyboard
Now the magic should happen, but there isn't a way to add a -layout
option to the X server, so the second seat remains black.I made a little
script to add that option to systemd-multi-seat-x (I renamed the original
systemd-multi-seat-x to systemd-multi-seat-x.org)
#!/bin/bash
echo $@/var/log/multiseat.log
layout=$(echo $@ | awk '{print $8}')
/lib/systemd/systemd-multi-seat-x.org $@ -layout $layout
exit
Unfortunately, still no gdm or an other Xserver on seat1
The X server tries to start the right ServerLayout
...
[ 1160.624] (++) ServerLayout seat1
[ 1160.624] (**) |--Screen TV (0)
[ 1160.624] (**) | |--Monitor default monitor
[ 1160.624] (**) | |--Device seat1
[ 1160.624] (==) No monitor specified for screen TV.
Using a default monitor configuration.
[ 1160.624] (**) Option IsolateDevice PCI:02:00:0
[ 1160.624] (**) Option SingleCard true
[ 1160.624] (==) Automatically adding devices
[ 1160.624] (==) Automatically enabling devices
[ 1160.624] (==) Automatically adding GPU devices
...
But ends with:
...
[ 1160.689] (EE) No devices detected.
[ 1160.689]
Fatal server error:
[ 1160.690] no screens found
[ 1160.690] (EE)
I figured out that I can start a second Xserver with gnome3:
#DISPLAY=:1 startx -- -layout seat1 -sharevts
But this gnome session isn't aware of any udev seat rules so it isn't
really working
#DISPLAY=:1 startx -- -layout seat1 -sharevts -seat seat1
Ends with the same Fatal server error:
...
[ 2188.890] (EE) No devices detected.
[ 2188.890]
Fatal server error:
[ 2188.890] no screens found
[ 2188.890] (EE)
Bugs https://bugzilla.redhat.com/show_bug.cgi?id=878605
and https://bugzilla.redhat.com/show_bug.cgi?id=962907
about the same problem already exist, but aren't solved.
I hope that some of the developers will fix this issue.
Floris
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: wording and grammar updates
--- man/machinectl.xml | 14 ++-- man/systemctl.xml | 180 - man/systemd.journal-fields.xml | 8 +- 3 files changed, 101 insertions(+), 101 deletions(-) diff --git a/man/machinectl.xml b/man/machinectl.xml index 2606180..8a96d42 100644 --- a/man/machinectl.xml +++ b/man/machinectl.xml @@ -91,9 +91,9 @@ termoption--property=/option/term listitemparaWhen showing -session/user properties, limit -display to certain properties as -specified as argument. If not +session/user properties, limit the +output to certain properties as +specified by the argument. If not specified, all set properties are shown. The argument should be a property name, such as @@ -109,7 +109,7 @@ listitemparaWhen showing unit/job/manager properties, show all -properties regardless whether they are +properties regardless of whether they are set or not./para/listitem /varlistentry @@ -159,8 +159,8 @@ commandkill-session/command or commandkill-user/command, choose which signal to send to selected -processes. Must be one of the well -known signal specifiers, such as +processes. Must be one of the well-known +signal specifiers, such as constantSIGTERM/constant, constantSIGINT/constant or constantSIGSTOP/constant. If @@ -221,7 +221,7 @@ or more registered virtual machines or containers or the manager itself. If no argument is specified, properties -of the manager will be shown. If a an +of the manager will be shown. If an ID is specified, properties of this virtual machine or container are shown. By default, empty properties diff --git a/man/systemctl.xml b/man/systemctl.xml index 07e7363..f550215 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -99,12 +99,12 @@ along with systemd; If not, see http://www.gnu.org/licenses/. (types and states can be mixed)./para paraIf one of the arguments is a unit type, when listing - units, limit display to certain unit types. Otherwise units + units, limit display to certain unit types. Otherwise, units of all types will be shown./para paraIf one of the arguments is a unit load state, when listing units, limit display to certain unit - types. Otherwise units of in all load states will be + types. Otherwise, units of in all load states will be shown./para paraAs a special case, if one of the arguments is @@ -120,10 +120,10 @@ along with systemd; If not, see http://www.gnu.org/licenses/. listitem paraWhen showing unit/job/manager properties with the commandshow/command command, limit display to certain - properties as specified as argument. If not specified all + properties as specified as argument. If not specified, all set properties are shown. The argument should be a comma-separated list of property names, such as - literalMainPID/literal. If specified more than once all + literalMainPID/literal. If specified more than once, all properties with the specified names are shown./para /listitem /varlistentry @@ -159,8 +159,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. termoption--before/option/term listitem - paraShow which units are started after, resp. before - with commandlist-dependencies/command. + paraShow which units are started after or before + with commandlist-dependencies/command, respectively. /para /listitem /varlistentry @@ -191,7 +191,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. listitem paraIf the requested operation conflicts with a pending - unfinished job, fail the command. If this is not specified +
[systemd-devel] systemd: more documentation nitpicks
The following changes since commit fec79699da51a0815ff01e14abcc94b1f6d3926a: hwdb: import data (2013-07-08 11:46:44 +0200) are available in the git repository at: git://git.inai.de/systemd manpages for you to fetch changes up to c5455203b23ac1bb02b8f1d62818d02540b890ed: man: wording and grammar updates (2013-07-08 16:22:36 +0200) Jan Engelhardt (1): man: wording and grammar updates man/machinectl.xml | 14 ++-- man/systemctl.xml | 180 - man/systemd.journal-fields.xml | 8 +- 3 files changed, 101 insertions(+), 101 deletions(-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 10:06:11AM +0200, Holger Hans Peter Freyther wrote: On Fri, Jun 28, 2013 at 09:43:08AM +0200, Peter Sztanojev wrote: So this issue is about tweaking how jenkins does its job? I have added David Strauss to the CC, hopefully he won't mind. Well, that is one part. make test really just checks if the test/ directory exists, it doesn't really contribute to the quality control. ping? I just checked the current build log and it is still issuing a make test (which still tests if the test directory exists). I think executing make check and make distcheck would be more approriate. cheers holger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] RFC: journald: Allow to cache the cg_get_root_path
On 06/27/2013 06:30 PM, Holger Hans Peter Freyther wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com Allow to cache the cg_get_root_path and introduce a new method cg_pid_get_path_shifted_with_root that can use the cached version instead of allocating a new string. My 2c, I have been thinking about something similar albeit a bit more generic. According to my analysis /proc access is costly and it would be best to cache the result for later use. Difficulty comes from trying to keep cache up to date, though. I've just started looking into connector's cn_proc which _seem_ to offer all the required functionality (fork, exec, exit notifications). I have to finish my prototype to verify if it's worth complications it brings. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADSUP] systemd Hackfest Brno Aug 6th/7th (colocated with GUADEC)
Heya! On Aug 6th/7th we'll have our next systemd hackfest, again at Brno in the Czech Republic, colocated with GAUDEC. https://plus.google.com/events/cb1urr7jt5p4voutfelci14c5qc If you are hacking on systemd, please join us in Brno, attendance is free! We can probably organize some funding for travel/lodging for a few people. If you'd like to attend and would need funding for that, please reply to this mail and let me know personally, and we'll try to figure something out. There's also going to be another hackfest at the Linux Plumbers conference in New Orleans, hence if you are from the US and would like to attend it might make more sense going there rather than travelling all the way to Europe. Tom, Dave, Johann, Zbigniew, what about you guys? Do you already have funding? Do you want to join us in Brno? Or are do you plan to go to LPC instead? Anybody else? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
On Sat, Jul 6, 2013 at 1:40 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: The patch I mailed a few hours ago about chowning cgroups solved this issue here. but it's not a permanent solution - only a workaround. I believe from the release notes that systemd --user shouldn't maintain the cgroups itself anymore directly and instead delegate to systemd-run(?). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] static-nodes: move creation of static nodes from udevd to tmpfiles
On Mon, Jul 8, 2013 at 9:09 AM, Umut Tezduyar u...@tezduyar.com wrote: Hi. I thought they serve for the same purpose. One generates device node information, other one creates the devices. I have no objection either but I thought we have documentation etc ready for systemd-static-nodes.service. I pushed this as is, we could change it in the future. If you are keeping kmod-static-nodes.service, maybe we should consider the configure flag for tmpfile support. If tmpfile support is not enabled, generated device file means nothing, I guess.. Good point, changed that before pushing. Thanks, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] X fatal server error with -seat option
On Mon, 08.07.13 17:16, Floris (jkflo...@dds.nl) wrote: Because multiseat doesn't work out-of-the-box with the Nvidia drivers I try to figure out why. THis is probably something you want to discuss with the Nvidia and X people. systemd just provides tagging of the devices. How the devices are accessed and assembled happens entirely on the X side these days. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Orchestrating a shutdown immediately after boot
On Mon, 08.07.13 00:08, Kerrick Staley (kerr...@kerrickstaley.com) wrote: I'd like my system to: 1. boot 2. run a command 3. shut down I've implemented step 2 in a .service file [1], but I can't figure out how to automatically shut the system down once it's finished. shutdown.target conflicts with all services that don't set DefaultDependencies=false (which is most of them), so it seems I'm out of luck—there is no way to specify a target that requires both multi-user.target and shutdown.target. Is there some way to handle this situation? You cannot queue bootup and shutdown in the same transaction. If you do then both transactions will be merged and hence the stop and start jobs for your units will conflict and one of them removed. The start-up transaction should be left as it is. And after the work you want to do is done you should simply queue another transactaion. N.B. This is all running in an LXC; the overarching goal is to sandbox the command so it can't affect the rest of the system. - Kerrick [1] If it's useful, the .service file is as follows: [Unit] Description=Sandboxed Checkerbox command After=multi-user.target [Service] User=user Type=simple ExecStart=/bin/sh -c '/home/user/cmd /home/user/stdin /home/user/stdout 2/home/user/stderr' A simple approach could be to simply add ExecStopPost=/usr/bin/systemctl --no-block poweroff or so. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal and /run/systemd/journal/syslog
On Sun, 07.07.13 19:18, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, I have noticed that if journal fails to send messages to /run/systemd/journal/syslog, it increments a counter and every 30 seconds it prints out a message on journal informing that forwarding x many messages has failed. If journal storage is set to none, there is no way of being informed about the missing messages. Should we not try to send a message to /run/systemd/journal/syslog if/when it has space again? Yes, sounds sensible. Added to the TODO list. syslog.socket sets ReceiveBuffer=8M. My understanding is intention of setting this value is specifying the maximum size of one datagram message that is allowed to send. socket.c is setting the SO_RCVBUF on the socket. According to man unix 7, SO_RCVBUF has no effect on the datagram but SO_SNDBUF does. Am I missing something? Oh, hm, this sucks. I wasn't aware of this. I always assumed SO_RCVBUF and SO_SNDBUF would both alter the same buffer, just from differente sides. Number of messages that can be queued on /run/systemd/journal/syslog is controlled by /proc/sys/net/unix/max_dgram_qlen and this value is by default 10 in most distributions. What this means is, after journal forwards 11 messages to the socket, it will not be able to do so until external logging daemon comes up and clears up /run/systemd/journal/syslog. If logging daemon is starting after basic.target, it is pretty certain that it will not be able to receive all the early boot messages. Increasing /proc/sys/net/unix/max_dgram_qlen is an option but is increasing a system wide limit right thing to do? Yeah, this is a big issue. For a long time there has been an item on the kernel wishlist to get an ioctl for setting the qlen per-socket. The code for that should actually be simple. We though about just bumping this globally via sysctl, but we feared that might not sit well with some folks, as we shouldn't change a global setting just because one user of it would benefit, especially given that we don't know the effect this might have on others... The better approach really appeared to us to be fixing the kernel properly instead, and get that new ioctl. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to destroy cgroup /system.slice/plymouth-start.service: Device or resource busy
On Sat, 06.07.13 19:44, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
Hi:
With v205, I sometimes get at boot time:
Failed to destroy cgroup /system.slice/plymouth-start.service:
Device or resource busy
void unit_destroy_cgroup(Unit *u) {..
r = cg_trim_with_mask(u-cgroup_mask, u-cgroup_path, true); ...
calls:
cg_trim(SYSTEMD_CGROUP_CONTROLLER, path, delete_root);
--delete_root is true..
int cg_trim(const char *controller, const char *path, bool delete_root) {
...
if (delete_root) {
if (rmdir(fs) 0 errno != ENOENT) -- here rmdir() fails
with EBUSY because path is currently in use..
return -errno;
}
Hmm, plymouth-start.service sets KillMode=none, since it wants to
survive the initrd→host transitions. Not sure what the right approach is
here, but I figure we should just no generate any error message in this
case and simply proceed.
I have now changed this to generate a debug message rather than an error
message. THis should make this invisible for normal boots.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
