Re: [systemd-devel] [gummiboot][RFC] Add trusted boot (tboot) support to gummiboot
10.11.2014 14:10, Minchev, Todor wrote: Hello guys, I have been working on adding trusted boot (tboot) support to gummiboot and since this requires quite a bit of new code to be added to the gummiboot code base I wanted to send it out for review and comments. This is the new functionality that these patches add to the gummiboot master branch: - trusted boot support via the tboot module and Intel's Trusted Execution Technology (TXT) - partial multiboot2 support for passing data to the trusted boot module - booting non efi_stub kernels via tboot - no impact on the existing gummiboot functionality I have not looked at the code, but looked at the list of commit messages. In particular: gummiboot: load the loadable segments of the ELF binary and jump to its entry point address As far as I understand, this goes against the design goals of gummiboot of being a simple wrapper that is able to execute EFI binaries and only them. Would it be feasible to convert tboot into an EFI binary instead, and measure/validate it as such, using the API provided by UEFI for that? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udevd and quiet
Hi, Not sure how long this has been the case, but in a dracut initrd that is NOT using systemd, udevd will print out starting version 217 even when quiet is used on the command line. This isn't ideal as it should be mostly silent when quiet is used and indeed this is the only output from the initrd. So question is, what is the correct fix. I don't really like the idea of udevd parsing quiet directly as this should really only apply to pid1. So perhaps dracut (as PID1 at that stage) should parse the quiet command line and set SYSTEMD_LOG_LEVEL=warning (or err?) before starting udevd (it doesn't seem that udevd takes any --log-level= (and friends) arguments, so the environment seems the only way). Is this the right approach or am I maybe missing something? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd and quiet
Colin Guthrie wrote on 10/11/14 10:11: Hi, Not sure how long this has been the case, but in a dracut initrd that is NOT using systemd, udevd will print out starting version 217 even when quiet is used on the command line. This isn't ideal as it should be mostly silent when quiet is used and indeed this is the only output from the initrd. So question is, what is the correct fix. I don't really like the idea of udevd parsing quiet directly as this should really only apply to pid1. So perhaps dracut (as PID1 at that stage) should parse the quiet command line and set SYSTEMD_LOG_LEVEL=warning (or err?) before starting udevd (it doesn't seem that udevd takes any --log-level= (and friends) arguments, so the environment seems the only way). Is this the right approach or am I maybe missing something? Hmm, this won't work it seems anyway, as right after log_parse_enviornment() and log_open() there is a call to: log_set_max_level(udev_get_log_priority(udev)); So it seems that an evnironment parsing is very swiftly overridden - which makes env parsing kinda pointless IMO. Any thoughts? CC'ing Tom as he changed the default log level to INFO recently in 2004d23a0fcaa6e74631057a2ff75594a038d86e which is likely why I'm seeing the bubble up now... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd and quiet
Sorry for the speaking to myself spam. Colin Guthrie wrote on 10/11/14 10:29: Colin Guthrie wrote on 10/11/14 10:11: Hi, Not sure how long this has been the case, but in a dracut initrd that is NOT using systemd, udevd will print out starting version 217 even when quiet is used on the command line. This isn't ideal as it should be mostly silent when quiet is used and indeed this is the only output from the initrd. So question is, what is the correct fix. I don't really like the idea of udevd parsing quiet directly as this should really only apply to pid1. So perhaps dracut (as PID1 at that stage) should parse the quiet command line and set SYSTEMD_LOG_LEVEL=warning (or err?) before starting udevd (it doesn't seem that udevd takes any --log-level= (and friends) arguments, so the environment seems the only way). Is this the right approach or am I maybe missing something? Hmm, this won't work it seems anyway, as right after log_parse_enviornment() and log_open() there is a call to: log_set_max_level(udev_get_log_priority(udev)); So it seems that an evnironment parsing is very swiftly overridden - which makes env parsing kinda pointless IMO. Any thoughts? CC'ing Tom as he changed the default log level to INFO recently in 2004d23a0fcaa6e74631057a2ff75594a038d86e which is likely why I'm seeing the bubble up now... recently fail... I misread the year! :D So looking at this further, it seems that dracut has kernel command line options to tweak the log level of dracut via udevadm control. The fact that it has an option to tweak it *to* info suggest that dracut assumes it's something else, and I'd guess it assumes err. So I think the correct behaviour here is to just set UDEV_LOG=err unconditionally in dracut and let the udevadm control options kick in later. Either that or a slight tweak to avoid the udevadm control altogether, and just set UDEV_LOG correctly from the beginning but not sure how well that works with older udev versions and whether or not UDEV_LOG env var works with older udevs that are still supported? Anyway, I guess this is one to follow up with Harald on the initramfs ML. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On 09/11/14 02:08, Casey Schaufler wrote: Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you want a system bus and a user bus with different attributes you want it to get the Smack label at launch time, just like you do for UID and capability sets. I think there's a much more fundamental reason why SMACK64EXEC would be a bad idea for dbus[1], which is that dbus-daemon has not been designed to distrust its caller and prevent privilege escalation from its caller's privileges to its own privileges. I think an executable can only safely be setuid, or other frameworks' equivalents of setuid (setcap, SMACK64EXEC, etc.), if the developers of that executable are fully aware that it is a privilege boundary in that way, and are designing it (and choosing its library dependencies!) with that in mind. This is not the case for dbus-daemon. It is entirely possible (although IMO unlikely) that, by coincidence, dbus-daemon does not currently have privilege escalations from its caller's privileges to its own privileges; but if we introduced such a thing (executing a command given by an environment variable, perhaps), I would not consider that to be a regression, because we never claimed it was suitable for that use. This is not unique to dbus; it applies equally to any project that releases executables. Note that dbus-daemon --system is designed to be a different sort of privilege boundary: it enforces differing privilege levels for applications that connect to it via D-Bus, and we do treat holes in that policy as security flaws. That still doesn't mean it is designed to be suitable for setuid. S [1] I assume you mean dbus-daemon, which is an executable; dbus is a package containing dbus-daemon, some other executables, and the libdbus library. There is no such thing as /usr/bin/dbus. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On 11/10/2014 08:57 PM, Simon McVittie wrote: On 09/11/14 02:08, Casey Schaufler wrote: Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you want a system bus and a user bus with different attributes you want it to get the Smack label at launch time, just like you do for UID and capability sets. I think there's a much more fundamental reason why SMACK64EXEC would be a bad idea for dbus[1], which is that dbus-daemon has not been designed to distrust its caller and prevent privilege escalation from its caller's privileges to its own privileges. I think an executable can only safely be setuid, or other frameworks' equivalents of setuid (setcap, SMACK64EXEC, etc.), if the developers of that executable are fully aware that it is a privilege boundary in that way, and are designing it (and choosing its library dependencies!) with that in mind. This is not the case for dbus-daemon. It is entirely possible (although IMO unlikely) that, by coincidence, dbus-daemon does not currently have privilege escalations from its caller's privileges to its own privileges; but if we introduced such a thing (executing a command given by an environment variable, perhaps), I would not consider that to be a regression, because we never claimed it was suitable for that use. This is not unique to dbus; it applies equally to any project that releases executables. Note that dbus-daemon --system is designed to be a different sort of privilege boundary: it enforces differing privilege levels for applications that connect to it via D-Bus, and we do treat holes in that policy as security flaws. That still doesn't mean it is designed to be suitable for setuid. S [1] I assume you mean dbus-daemon, which is an executable; dbus is a package containing dbus-daemon, some other executables, and the libdbus library. There is no such thing as /usr/bin/dbus. Ah..dbus-daemon was just a example as a well known daemon. Actually, this problem was occurred on email-service daemon. Currently, that has system::email SMACK label. Please forgot I'd mentioned about dbus-daemon. Currently, we are using daemon-daemon with _ label like other system daemon. I wonder about other guys also confused about this. Thanks WaLyong ___ 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] [PATCH] smack: introduce new SmackLabelExec option
On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote: Calling it SmackLabel= instead of SmackLabelExec= would be fine as far as I'm concerned. SmackLabel= is more consistent with SELinuxContext= and AppArmorProfile=, as you point out. OK! WaLyong, let's name it SmackLabel= then! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
On Fri, 07.11.14 20:59, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: Hi, I know that generators should log to /dev/kmsg during early boot. Correct! But, when they are restarted later by systemcl daemon-reload; is it better to write to the journal instead, by using systemd-cat for example ? Or is it racy/forbidden ? Yes, this is dangerous. During a daemon-reload PID 1 serilizes its state to a file in /run, then flushes all configuration, then invokes the generators, and then rereads the configuration and deserializes the state. Now, if you generator accesses the journal socket, and journald is not running yet (because you are in emergency mode for example), then things might deadlock: as logging is synchronous and the socket buffer is limited in size your generator might block while writing the log message and since activation cannot take place as PID 1 is not processing any events while doing the whole state flush/config flush/generator magic/config reload/state reload it would never unblock again. Generators really really shouldn't talk to any other services, and this means for logging they should log to /dev/kmsg or suchlike. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remount
On Fri, 07.11.14 15:35, Fisher, Charles J. (Top Echelon) (charles.fis...@alcoa.com) wrote: When I start a container like this: [root@limsdev ~]# systemd-nspawn -bD /home/limsbox --bind-ro=/usr/lib64 --bind-ro=/home/oracle/Ora12c/db Is there any way I can stop the container root from being able to do this?: ~ # mount -o remount,rw /usr/lib64 Disallowing that would mean taking CAP_SYS_ADMIN away from the container. However that takes away quite a few different features, including *any* kind of mounting. However, systemd relies on that to properly implement PrivateTmp= and similar bits that require setting up a mount namespace and bind mounting things within it. That said, you actually can drop the cap, with the --drop-capability=CAP_SYS_ADMIN switch, but YMMV. Containers are really not about security, there are tons of security holes in the entire scheme. We make this abundantly clear in the man page of nspawn... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On 11/10/2014 10:26 PM, Lennart Poettering wrote: On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote: Calling it SmackLabel= instead of SmackLabelExec= would be fine as far as I'm concerned. SmackLabel= is more consistent with SELinuxContext= and AppArmorProfile=, as you point out. OK! WaLyong, let's name it SmackLabel= then! I think I had made you to bother. Excuse me, but I'm asking you again. And I think introducing new config should be careful. Hmm, I'm still confusing. We're already using SmackLabel= as socket config item. Yeah, it can possible as both exec/socket config. But each purposes are different. In socket config, this config is used to set SMACK64 of socket file. In exec config, this config is used to set child systemd attribute when User= config is given. And does we have to explain each man page? Or drop from socket package and move that to exec page? I'm not sure it make sense. Thanks WaLyong Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
Le lundi 10 novembre 2014, 14:32:49 Lennart Poettering a écrit : I know that generators should log to /dev/kmsg during early boot. Correct! Yes, but then the log appears as a ugly big chunck without the timestamp host on the left; except the first line. Is it ok to reopen /dev/ksmg for each line writen to avoid this ? Google gave me this: http://unix.stackexchange.com/questions/35639/how-can-i-write-to-dmesg-from-command-line With take me back here :-) ! which is easy to understand. http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-kmsg.c (...) deadlocks (...) Ok, I indeed got some while doing tests for my /var/spool/cron/crontabs problem. I finally settled to generate a kind of 'transient' service that does a daemon-reload ; restart cront.target _only_ if this path doesn't exist; and it iself contains a ConditionDirectoryNotEmpty=/var/spool/cron/crontabs to avoid needless daemon-reload. The twist: on the second run of the generator, this path now _does_ exist; so this service doesn't generate itself again. At first, I had used 'ExecStartPost=' for the restart part ; but the .service simply vanish during the daemon-reload and can never finish. (this behaves like a self-modifying shell script) Now I do this, it turns the ExecStart in a kind of atomic operation: ExecStart=/bin/sh -c /bin/systemctl daemon-reload ; /bin/systemctl try-restart cron.target https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L471 Generators really really shouldn't talk to any other services, and this means for logging they should log to /dev/kmsg or suchlike. So we should also avoid sending mail with /usr/sbin/sendmail , for example ? Thanks, Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?
Hi there! Currently there are few alternatives for implementing guest accounts in Linux systems. I know only two: an AppArmor-based approach implemented in LightDM, and a SELinux-based approach implemented in Fedora's package xguest that works with GDM. There's no option for console guest login (should it be needed?). I was thinking if systemd-logind could handle itself guest accounts in the future, making it available for use by any display manager (and even console logins, who knows?). What do you think about it? -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal Professor Eulálio Gruppi* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
On Mon, 10.11.14 17:38, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: Le lundi 10 novembre 2014, 14:32:49 Lennart Poettering a écrit : I know that generators should log to /dev/kmsg during early boot. Correct! Yes, but then the log appears as a ugly big chunck without the timestamp host on the left; journalctl should pretty much generate the same output for userspace messages written to /dev/kmsg then to those passed directly to journald. except the first line. Is it ok to reopen /dev/ksmg for each line writen to avoid this ? Not sure I follow? So we should also avoid sending mail with /usr/sbin/sendmail , for example ? Yes, that's really not an OK thing to do. /usr/sbin/sendmail might talk to a local service for delivering the mail, as well as syslog again for its own logging needs. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd and quiet
On Mon, 10.11.14 10:11, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Not sure how long this has been the case, but in a dracut initrd that is NOT using systemd, udevd will print out starting version 217 even when quiet is used on the command line. Hmm, that message is printed at LOG_INFO log level. quiet should normally turn that off, but leave LOG_NOTICE and worse shown. Are you saying that doesn't work correctly? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On Tue, 11.11.14 00:43, WaLyong Cho (walyong@samsung.com) wrote: On 11/10/2014 10:26 PM, Lennart Poettering wrote: On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote: Calling it SmackLabel= instead of SmackLabelExec= would be fine as far as I'm concerned. SmackLabel= is more consistent with SELinuxContext= and AppArmorProfile=, as you point out. OK! WaLyong, let's name it SmackLabel= then! I think I had made you to bother. Excuse me, but I'm asking you again. And I think introducing new config should be careful. Hmm, I'm still confusing. We're already using SmackLabel= as socket config item. Yeah, it can possible as both exec/socket config. But each purposes are different. In socket config, this config is used to set SMACK64 of socket file. In exec config, this config is used to set child systemd attribute when User= config is given. And does we have to explain each man page? Or drop from socket package and move that to exec page? I'm not sure it make sense. Hmm, OK, so you might actually have a point. And this is because .socket units may carry ExecStartPre= command lines which are execute before we start listening to a socket. If we'd just have SmackLabel= then it would not be clear whether it applies as file system label to the socket fds, or if it applies as process label to the ExecStartPre= processes. Hmm, I guess I am fine with SmackLabelExec= then! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] shared/install: when unit contains only Also=, report 'indirect'
On Fri, 07.11.14 21:21, Jan Synacek (jsyna...@redhat.com) wrote: If a unit contains only Also=, with no Alias= or WantedBy=, it shouldn't be reported as static. New 'indirect' status shall be introduced. Thanks! Applied! (Made one more commit afterwards changing the description of the new unit file state a bit in the man page). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: explicitly ignore the return value of wait_for_terminate
On Sun, 09.11.14 15:51, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: CID#1237532 CID#1237523 CID#1237522 Applied! Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user environment variables
On Fri, 07.11.14 20:40, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: We could probably at least open up DefaultEnvironment= to specifier expansion, so that %t would work the same way as in unit files. I added a TODO list item for this now. Thank you so much This refers to the recent flame about systemd. As a newbie, I can testify the dev team is doing everything to help. As for the variable, two more wishes (not a big deal yet): - in units, why not add a specifier reflecting $XDG_CONFIG_HOME Hmm, when we start with that, then I figure people want the other XDG dirs as well, soon... Anyway, what's the usecase for this? - why not systemctl --export-environment Same here, what's the usecase? (Not really opposed to either, but I'd like to hear a usecase first) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thu, 06.11.14 16:59, Colin Guthrie (gm...@colin.guthr.ie) wrote: Simon McVittie wrote on 06/11/14 15:21: On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote: What matters is how it is all arranged: - if there's a job that does stuff, and then calls reboot or shutdown - a hook into the shutdown or reboot target does some work unattended-upgrades is currently the latter: the user shuts down (or is reminded to shut down by an update notification), and unattended-upgrades runs as a side-effect. This is an optional (non-default) configuration of an optional package, not core Debian/Ubuntu functionality; so it doesn't necessarily have to be like this forever, it could be modified to tell systemd I'm still shutting down, continue to wait periodically, it could be modified to use reboot into a special mode, install, then reboot again logic under systemd if that's something you already have, and, worst-case, it could install a drop-in to override the timeout. Was there not talk of teaching the sd-notify protocol the ability to tell systemd that I'm still alive and doing stuff - so please don't kill me? That exists since quite some time. It's the WATCHDOG= field in sd_notify() Not sure if this is really useful here though... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
Yes, but then the log appears as a ugly big chunck without the timestamp host on the left; except the first line. Is it ok to reopen /dev/ksmg for each line writen to avoid this ? Not sure I follow? This might be a trivial problem; it's just that there are really few people writing generators or outputing do /dev/kmsg . Here is a sample test case the 2 different behaviours, maybe a flush after the write would do it: root@antec:/home/tchet# cat log 4 log1: log1 4 log2: log2 4 log3: log3 4 log4: log4 root@antec:/home/tchet# LANG=C dd if=log of=/dev/kmsg 0+1 records in 0+1 records out 60 bytes (60 B) copied, 0.000114992 s, 522 kB/s root@antec:/home/tchet# while read level pgm msg; do echo $level $pgm $msg /dev/kmsg; done log root@antec:/home/tchet# journalctl -n ... nov 10 20:25:06 antec log1: log1 4 log2: log2 4 log3: log3 4 log4: log4 nov 10 20:25:20 antec log1: log1 nov 10 20:25:20 antec log2: log2 nov 10 20:25:20 antec log3: log3 nov 10 20:25:20 antec log4: log4 Yes, that's really not an OK thing to do. /usr/sbin/sendmail ... Ok, I don't want to test this with 20 differents MTA anyway. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote: Please boot with systemd.log_level=debug, then make the machine hang and check what the last things in the logs say. Maybe then paste that somewhere online and post the URL for that here, so that we can have a look. Here's the output (obtained by changing log level and remounting earlier in the debug.sh script): https://dl.dropboxusercontent.com/u/11545826/shutdown.log Thanks for your help! Hmm the logs show that systemd pretty much completed its shutdown. After the message Cannot finalize remaining DM devices, continuing. the only thing that still runs is the shutdown hooks you used to generate this log, plus either a jump back into your initrd (if your initrd supports that) or the reboot() system call. If the latter hangs then it's a kernel bug. Please check if there are any other scripts in /lib/systemd/system-shutdown/ that might be at fault here. Please check if your initrd is one of those which support jumping back into the initrd on shutdown. For that check if /run/initramfs/shutdown exists during runtime and is executable. If so, it's probably an initrd problem, please file a bug against your initrd implementation. You appear to be using LVM, I wouldn't be surprised if LVM is broken here, but I cannot help you debugging this, please contact the LVM maintainers in this case. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
On Mon, 10.11.14 20:30, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: Yes, but then the log appears as a ugly big chunck without the timestamp host on the left; except the first line. Is it ok to reopen /dev/ksmg for each line writen to avoid this ? Not sure I follow? This might be a trivial problem; it's just that there are really few people writing generators or outputing do /dev/kmsg . Here is a sample test case the 2 different behaviours, maybe a flush after the write would do it: root@antec:/home/tchet# cat log 4 log1: log1 4 log2: log2 4 log3: log3 4 log4: log4 root@antec:/home/tchet# LANG=C dd if=log of=/dev/kmsg 0+1 records in 0+1 records out 60 bytes (60 B) copied, 0.000114992 s, 522 kB/s root@antec:/home/tchet# while read level pgm msg; do echo $level $pgm $msg /dev/kmsg; done log root@antec:/home/tchet# journalctl -n ... nov 10 20:25:06 antec log1: log1 4 log2: log2 4 log3: log3 4 log4: log4 nov 10 20:25:20 antec log1: log1 nov 10 20:25:20 antec log2: log2 nov 10 20:25:20 antec log3: log3 nov 10 20:25:20 antec log4: log4 The kernel does some moronic line merging there. Consider just reopening the device each time to avoid it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user environment variables
As for the variable, two more wishes (not a big deal yet): - in units, why not add a specifier reflecting $XDG_CONFIG_HOME Hmm, when we start with that, then I figure people want the other XDG dirs as well, soon... Anyway, what's the usecase for this? Just laziness when writing service files.conf Ex: gpg-agent.conf [Service] Environment=GNUPGHOME=%h/.config/gnupg I often use the path sequence '%h/.config'. So forget about it, laziness is not a valuable reason - why not systemctl --export-environment Same here, what's the usecase? No usecase at the moment. I can imagine one day a systemctl started service with an exported variable to systemd env and then need to pass the variable to the user env for any other services. Again, not yet a big deal. (Not really opposed to either, but I'd like to hear a usecase first) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] s/commandline/command line/g
On Thu, Nov 6, 2014 at 9:37 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 05.11.14 14:56, har...@redhat.com (har...@redhat.com) wrote: +++ b/man/systemd-run.xml @@ -215,7 +215,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. /variablelist paraAll command-line arguments after the first non-option -argument become part of the commandline of the launched +argument become part of the command line of the launched process. If a command is run as service unit, its first argument needs to be an absolute binary path./para /refsect1 I figure there are some more cleanups to be done here... The example above shows that we not only use commandline and command line, but also command-line... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel command-line is the proper spelling when used as an adjective. command line is correct when it is a noun. For example, command-line options is correct, and enter foo on the command line is also correct. But if you switch which example gets the hyphen, then they are both grammatically *in*correct. In any case, commandline is always incorrect. A simple find and replace of command-line to command line will introduce numerous grammatical errors. Jason P.S. Lennart, sorry for the duplicate email. I just realized that my previous email was sent to you only instead of to the mailing list. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd and quiet
Lennart Poettering wrote on 10/11/14 18:54:
On Mon, 10.11.14 10:11, Colin Guthrie (gm...@colin.guthr.ie) wrote:
Hi,
Not sure how long this has been the case, but in a dracut initrd that is
NOT using systemd, udevd will print out starting version 217 even when
quiet is used on the command line.
Hmm, that message is printed at LOG_INFO log level. quiet should
normally turn that off, but leave LOG_NOTICE and worse shown.
Well according to:
shared/log.c:880: * However, quiet is only parsed by PID 1!
it seems that quiet is only parsed by PID 1, so this shouldn't affect
udevd running on it's own outside of systemd as PID 1 (which can be the
case in dracut - slowly working towards systemd in dracut but haven't
got the time/energy to debug all the crazy disk configurations our
installer lets you imagine up...).
Are you saying that doesn't work correctly?
It certainly appears not to work for udevd, and looking at the code in
src/udev/udevd.c makes this rather obvious.
Line 1119:
log_set_target(LOG_TARGET_AUTO);
log_parse_environment();
log_open();
udev_set_log_fn(udev, udev_main_log);
log_set_max_level(udev_get_log_priority(udev));
So after setting the log level from the environment, we also set it from
udev_get_log_priority() which, since
2004d23a0fcaa6e74631057a2ff75594a038d86e will ultimately return LOG_INFO
if no other factors interfere.
So regardless of SYSTEMD_LOG_LEVEL environment var, the built in log
level will always override it, whether this is LOG_INFO or overridden by
/etc/udev/udev.conf or UDEV_LOG env var.
IMO this should be fixed. Probably the simplest fix that retains
backwards compatibility is this (untested) which honours
SYSTEMD_LOG_LEVEL but still prefers UDEV_LOG:
diff --git a/src/libudev/libudev.c b/src/libudev/libudev.c
index b1649b6..127b85c 100644
--- a/src/libudev/libudev.c
+++ b/src/libudev/libudev.c
@@ -207,6 +207,8 @@ _public_ struct udev *udev_new(void)
/* environment overrides config */
env = secure_getenv(UDEV_LOG);
+if (isempty(env))
+env = secure_getenv(SYSTEMD_LOG_LEVEL);
if (env != NULL) {
int prio;
But AFAICT all this still doesn't prevent quiet on the kernel command
line having zero effect on udevd's default log level :)
So either we teach udevd to parse quiet itself when setting it's default
log level or we simply fix dracut to set UDEV_LOG env var to ensure the
log level is set, as it expects, set to err (it could write a
/etc/udev/udev.conf but env var is easier). I posted such a dracut patch
to the initramfs@vger list earlier today.
http://thread.gmane.org/gmane.linux.kernel.initramfs/3879
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Poor man's reboot doesn't work
Am Freitag, den 07.11.2014, 01:59 +0100 schrieb Lennart Poettering: On Sun, 02.11.14 12:48, Thomas Meyer (tho...@m3y3r.de) wrote: Hi, I tried to switch to the emergency target and back to the graphical target, but this doesn't seem to work. Should this work, i.e.? # systemctl isolate emergency.target # systemctl isolate graphical.target The services seems to fail with this error once I'm in the emergency.target and try to switch back to the graphical.target: status=219/CGROUP Mhh, strange. the last two tries to reproduces this bug failed. everything worked as expected. Strange! anyway I'm going to upgrade to Fedora 21 in the next days. so I'll watch out for this bug again, then. thanks. thomas Hmm, this is certainly weird. Any chance you can do strace -ff -p 1 -o /tmp/someplace/log (maybe from the debug shell). Then, trigger the issue again, and find the tight log file in /tmp/someplace that ends with an exit(219). It would be good to paste that file somewhere (or at least the last few lines which might give an indication on what precisely fails), so that I can have a look. Also, try booting with debug logs on (systemd.log_level=debug) and see if this generates any additional log output that might be useful. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?
On Mon, 10.11.14 16:41, Laércio de Sousa (laercioso...@sme-mogidascruzes.sp.gov.br) wrote: Hi there! Currently there are few alternatives for implementing guest accounts in Linux systems. I know only two: an AppArmor-based approach implemented in LightDM, and a SELinux-based approach implemented in Fedora's package xguest that works with GDM. There's no option for console guest login (should it be needed?). I was thinking if systemd-logind could handle itself guest accounts in the future, making it available for use by any display manager (and even console logins, who knows?). What do you think about it? I figure this pays into the whole concept of dynamic users, which we really want to have eventually, to deal with dynamic allocation of UIDs for user namespacing in container managers, for allocating per-seat users for gdm login screens, and then also for your usecase, i.e. to implement guest users that go away entirely on logout. So yeah, it's definitely something we want, and I figure it should be added to the systemd project in some way. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thu, 06.11.14 14:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Nov 06, 2014 at 02:28:12PM +0100, Lennart Poettering wrote: On Thu, 06.11.14 12:45, Patrick Häcker (pa...@web.de) wrote: However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? At least unattended-upgrades from Debian/Ubuntu/... can be configured to install updates on shutdown (without any special mode or something). And, yes, this can run for more than 30 minutes, which I could already observe in its default mode (installing during normal system activities), so I see no reason why this should not happen when configured to install during shutdown. The reason is, that unattended-upgrades can basically update the whole distribution to the next version, which naturally can take a lot of time. It's questionable if this is a sane setup, but I can think of setups where this might be useful, e.g. having two identically configured servers for redundancy reasons where one server would be enough. Then it might make sense to update one system during shutdown while the other one takes over. This has the advantage, that normally running servers either have the old or the new state, but never some intermediate state during the update. The shutdown time does not really matter in this case and a watchdog killing the system wouldn't be welcome. But all in all this seems like an exotic use case. Is unattended-upgrades a package of its own? If so, I'd probably ask the packagers to include drop-ins for reboot.target to override the timeout. That way, as soon as you install it the shutdown timeouts are disabled. That is suboptimal. There really should be a way to this dynamically, like saying: I'm a log-running job, I need more time, but everything is still fine. This type of status should require periodical pings, watchdog style. Let's say that the backup job run during shutdown hangs because there's no network, we want to shutdown at some point anyway. So, we always had per-unit timeouts in place, and they are opt-out (with the exception of Type=oneshot services where they are opt-in). Hence adding a second level of opt-out timeouts doesn't sound particularly attractive to me. The reason I added the system-wide startup/shutdown timeouts was really to be a safety net, so that the individual per-unit timeouts and the opted-out exceptions don't add up beyond bounds. The specific usecase I had for this (beyond the obvious one in embedded/HA setups) was my Lenovo Yoga laptop. It has the power button on the outside, that is reachable even when the laptop is closed (this is due the fact that it is convertible into tablet mode, where the button needs to stay accessible). Now, if the system is suspended, and the lid closed, and the power button is accidentally hit because the laptop was stuffed in a backpack, then since a couple of versions ago is not a problem: after a short while the system will suspend again. However, if the machine is powered off with the lid closed, and the power-button is hit the machine powers up currently, then boots up until the LUKS prompt is hit and then just hangs there, forever, heating up my backpack, so then when I finally unpack it the battery is completely empty. I figure this is not only an issue with laptops like the Yoga but in general with all kinds of devices. Now, the question is what we can do now about this: a) we could move logind into early boot. This has multiple problems though: it would need to track system state as gettys on other ttys should only be started in multi-user mode, not in early boot. Also, the behaviour would probably not be ideal: i think it would be preferable if the system shuts down rather then suspend if we hang during boot. b) specifically do something about LUKS prompt timeouts: when a very long timeout is hit for essential devices we could simply turn off the machine again. This would fix my immediate problem, but I am not sure I like it too much, I think other hangs should really be covered too... c) we can come up with a scheme that explicitly excludes fsck, selinux relabel and so on from the overall-timeout. Sounds messy and non-obvious given that they all have individual timeouts anyway... Two layers of opting out of timeouts sounds suspicious? Any other ideas? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Poor man's reboot doesn't work
On Mon, 10.11.14 22:30, Thomas Meyer (tho...@m3y3r.de) wrote: Am Freitag, den 07.11.2014, 01:59 +0100 schrieb Lennart Poettering: On Sun, 02.11.14 12:48, Thomas Meyer (tho...@m3y3r.de) wrote: Hi, I tried to switch to the emergency target and back to the graphical target, but this doesn't seem to work. Should this work, i.e.? # systemctl isolate emergency.target # systemctl isolate graphical.target The services seems to fail with this error once I'm in the emergency.target and try to switch back to the graphical.target: status=219/CGROUP Mhh, strange. the last two tries to reproduces this bug failed. everything worked as expected. Strange! anyway I'm going to upgrade to Fedora 21 in the next days. so I'll watch out for this bug again, then. This really feels like a race. Something is removing the cgroup before we can add the process to the cgroup. One way to track this down might be to use Martin Pitt's fatrace tool to check which process is removing the cgroup ultimately. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service not restarting after Condition failed
On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se) wrote: Hi we have a service set to: ConditionFileNotEmpty= and Restart=Always This combination would (in my feebled mind) cause the service to restart once the Condition was fulfilled, but that doesn't seem to be the case. Conditions are something that are on-time evaluated right before we would start a unit, and cause this starting to be shortcut. That's all really. Restarts are only triggered when a running service dies, and the start job queued by that will then check the conditions again. If the condition doesn't hold then this start will not be executed, and hence no restart ever again either... Is there a way I can get a service to restart even after it has been set as inactive (dead) start condition failed? Nope, conditions are not for that. For the specific check of file-not-empty there's no nice way to handle this, however for directory-not-empty you could set up DirectoryNotEmpty=... Should I simply remove the Condition, or something else? What precisely are you trying to do? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6] tmpfiles, man: Add xattr support to tmpfiles
On Thu, 30.10.14 12:21, Maciej Wereski (m.were...@partner.samsung.com) wrote:
+static int get_xattrs_from_arg(Item *i) {
+_cleanup_free_ char *xattr = NULL;
+const char *p;
+int n;
+
+assert(i);
+if (i-type != SET_XATTR)
+return 0;
+
+if (!i-argument) {
+log_error(%s: Argument can't be empty!, i-path);
+return -EBADMSG;
+}
+p = i-argument;
+
+while ((n = unquote_first_word(p, xattr)) 0) {
+if (strv_extend(i-xattrs, xattr) 0)
+return log_oom();
+free(xattr);
+xattr = NULL;
+}
Please use strv_consume() or strv_push() here, to make the additional
copy unnecessary. Also please, generate a parse failure if
unquote_first_workd() fails due to parse errors.
+r = get_xattrs_from_arg(i);
+if (r 0)
+return r;
+
+if (strv_isempty(i-xattrs))
+return 0;
+
+STRV_FOREACH(x, i-xattrs) {
+_cleanup_free_ char *name = NULL, *value = NULL, *tmp = NULL;
+n = split_pair(*x, =, name, value);
+if (n 0)
+return n;
+tmp = unquote(value, \);
+if (!tmp)
+return log_oom();
+free(value);
+value = cunescape(tmp);
+if (!value)
+return log_oom();
+n = strlen(value);
+if (i-type == CREATE_SYMLINK) {
+if (lsetxattr(path, name, value, n+1, 0) 0) {
+log_error(Setting extended attribute %s=%s
on symlink %s failed: %m, name, value, path);
+return -errno;
+}
+}
+else if (setxattr(path, name, value, n+1, 0) 0) {
+log_error(Setting extended attribute %s=%s on %s
failed: %m, name, value, path);
+return -errno;
+}
The indentation is wrong.
Should the extended attribute value really include the trailing NUL
byte? I doubt it...
Shouldn't we always invoke lsetxattr() instead of setxattr()?
If we really should keep both around, I think a single error handling
for both if blocks would be better.
@@ -894,6 +983,12 @@ static int create_item(Item *i) {
r = glob_item(i, item_set_perms);
if (r 0)
return r;
+
+if (i-xattrs) {
+r = glob_item(i, item_set_xattrs);
+if (r 0)
+return r;
+}
break;
Hmm, ths would mean we resolve the globbing twice. Once for
item_set_perms() and once for item_set_xattr(). I think it would be
better to do this in one call.
case RECURSIVE_RELABEL_PATH:
@@ -901,8 +996,12 @@ static int create_item(Item *i) {
r = glob_item(i, item_set_perms_recursive);
if (r 0)
return r;
-
break;
+
+case SET_XATTR:
+r = item_set_xattrs(i, i-path);
+if (r 0)
+return r;
}
Misses the closing break;?
Looks OK otherwise.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] localed: validate set-x11-keymap input
On Tue, 04.11.14 12:05, Jan Synacek (jsyna...@redhat.com) wrote:
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index d4a2d29..8f9e4da 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -46,6 +46,7 @@
#include virt.h
#include fileio.h
#include locale-util.h
+#include xkb-util.h
static bool arg_no_pager = false;
static bool arg_ask_password = true;
@@ -389,14 +390,7 @@ static int set_x11_keymap(sd_bus *bus, char **args,
unsigned n) {
static int list_x11_keymaps(sd_bus *bus, char **args, unsigned n) {
_cleanup_fclose_ FILE *f = NULL;
_cleanup_strv_free_ char **list = NULL;
-char line[LINE_MAX];
-enum {
-NONE,
-MODELS,
-LAYOUTS,
-VARIANTS,
-OPTIONS
-} state = NONE, look_for;
+enum keymap_state look_for;
While we don#t follow this rule too strictly we usually define typdefs
for enums and name them in CamelCase. Hence, please rename this type
KeymapState instead of enum keymap_state.
That said, is state really the right name here? Shouldn't it be
field or component or item or so?
!streq_ptr(variant, c-x11_variant) ||
!streq_ptr(options, c-x11_options)) {
+_cleanup_free_ char *msg = NULL;
if ((layout !string_is_safe(layout)) ||
(model !string_is_safe(model)) ||
@@ -1050,6 +1052,12 @@ static int method_set_x11_keyboard(sd_bus *bus,
sd_bus_message *m, void *userdat
free_and_strdup(c-x11_options, options) 0)
return -ENOMEM;
+r = xkb_validate_keymaps(model, layout, variant, options,
msg);
+if (r 0) {
+log_error(Failed to validate X11 keyboard layout:
%s, strerror(-r));
+return sd_bus_error_set(error, SD_BUS_ERROR_FAILED,
msg);
+}
+
Please return the error back to the client instead of logging it
away. Use sd_bus_error_setf() for that.
Use SD_BUS_ERROR_INVALID_ARGS as error id.
+
+static char **xkb_parse_argument(const char *arg)
+{
+_cleanup_free_ char *input;
+char *token;
+char **result = NULL;
+int r;
+
+assert(arg);
+
+input = strdup(arg);
+if (!input)
+return NULL;
+
+token = strsep(input, ,);
+while(token) {
+r = strv_extend(result, token);
+if (r 0)
+return NULL;
+token = strsep(input, ,);
+}
+
+return result;
+}
Please place the opening { of a function body on the same line as the
function declaration.
I figure strv_split() does exactly the same thing, please use that.
+
+int xkb_get_keymaps(char ***list, enum keymap_state look_for, const char
*layout_prefix)
+{
+_cleanup_fclose_ FILE *f;
+char line[LINE_MAX];
+enum keymap_state state = NONE;
+int r;
+
+f = fopen(/usr/share/X11/xkb/rules/base.lst, re);
+if (!f) {
+log_error(Failed to open keyboard mapping list. %m);
+return -errno;
+}
This should probably become a function call that returns errors but
doesn't log about them, leaving that to the caller.
+int xkb_validate_keymaps(const char *model,
+ const char *layouts_arg,
+ const char *variants_arg,
+ const char *options_arg,
+ char **error)
+{
+int r;
+
+if (layouts_arg) {
+_cleanup_strv_free_ char **layouts_list = NULL;
+char **it, **layouts;
+int i = 0;
+
+r = xkb_get_keymaps(layouts_list, LAYOUTS, NULL);
+if (r 0)
+return r;
+
+layouts = strv_split(layouts_arg, ,);
+if (!layouts)
+return log_oom();
+
+STRV_FOREACH(it, layouts) {
+_cleanup_strv_free_ char **variants_list = NULL;
+bool variants_left = true;
+int n;
+
+if (!strv_find(layouts_list, *it)) {
+r = asprintf(error, Requested layout '%s'
not available.\n, *it);
+if (r 0)
+return log_oom();
+return -EINVAL;
+}
+
+if (variants_left variants_arg) {
+_cleanup_strv_free_ char **variants;
+
+r = xkb_get_keymaps(variants_list,
VARIANTS, *it);
+if (r 0)
+return r;
Re: [systemd-devel] [PATCH] localed: validate set-x11-keymap input
On Tue, 04.11.14 12:05, Jan Synacek (jsyna...@redhat.com) wrote:
One more addition:
+}
+
+int xkb_get_keymaps(char ***list, enum keymap_state look_for, const char
*layout_prefix)
+{
+_cleanup_fclose_ FILE *f;
+char line[LINE_MAX];
+enum keymap_state state = NONE;
+int r;
+
+f = fopen(/usr/share/X11/xkb/rules/base.lst, re);
+if (!f) {
+log_error(Failed to open keyboard mapping list. %m);
+return -errno;
+}
+
+FOREACH_LINE(line, f, break) {
+char *l, *w;
+
+l = strstrip(line);
+
+if (isempty(l))
+continue;
+
+if (l[0] == '!') {
+if (startswith(l, ! model))
+state = MODELS;
+else if (startswith(l, ! layout))
+state = LAYOUTS;
+else if (startswith(l, ! variant))
+state = VARIANTS;
+else if (startswith(l, ! option))
+state = OPTIONS;
+else
+state = NONE;
+
+continue;
+}
+
+if (state != look_for)
+continue;
+
+w = l + strcspn(l, WHITESPACE);
+
+if (layout_prefix) {
+char *e;
+
+if (*w == 0)
+continue;
+
+*w = 0;
+w++;
+w += strspn(w, WHITESPACE);
+
+e = strchr(w, ':');
+if (!e)
+continue;
+
+*e = 0;
+
+if (!streq(w, layout_prefix))
+continue;
+} else
+*w = 0;
+
+r = strv_extend(list, l);
+if (r 0)
+return log_oom();
I think, while we are at it, this should really be reworked to use
GREEDY_REALLOC. See strv_split_quoted() for an example.
+}
+
+if (strv_isempty(*list)) {
+log_error(Couldn't find any entries.); /* TODO: improve
error message */
+return -ENOENT;
+}
+
+return 0;
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] calendar: semesterly alias for semi-annually
On Thu, 30.10.14 12:19, Daniele Medri (dme...@gmail.com) wrote:
I am still not convinced that semesterly is really a good
addition. See previous comments about that:
I am a bit conservative about that. Semester has a very
academic touch to it, and at least in germany the semester
usually starts in october, not in january. I'd rather stay
away from this word hence, since at least to me it appears
to suggest something different than *-1,7-1...
And we do have semi-annually already that covers this nicely.
---
man/systemd.time.xml | 4 ++--
src/shared/calendarspec.c| 3 ++-
src/test/test-calendarspec.c | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/man/systemd.time.xml b/man/systemd.time.xml
index f35ccd7..2342684 100644
--- a/man/systemd.time.xml
+++ b/man/systemd.time.xml
@@ -247,8 +247,8 @@
literalmonthly/literal, literalweekly/literal,
literalyearly/literal,
literalquarterly/literal,
-literalsemiannually/literal may be used as
-calendar events which refer to
+ literalsemesterly/literal or literalsemiannually/literal
+ may be used as calendar events which refer to
literal*-*-* *:*:00/literal,
literal*-*-* *:00:00/literal,
literal*-*-* 00:00:00/literal,
diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 7efcf7b..3115bba 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -757,7 +757,8 @@ int calendar_spec_from_string(const char *p, CalendarSpec
**spec) {
} else if (strcaseeq(p, biannually) ||
strcaseeq(p, bi-annually) ||
strcaseeq(p, semiannually) ||
- strcaseeq(p, semi-annually)) {
+ strcaseeq(p, semi-annually) ||
+ strcaseeq(p, semesterly)) {
r = const_chain(1, c-month);
if (r 0)
diff --git a/src/test/test-calendarspec.c b/src/test/test-calendarspec.c
index 87e1da1..7610cff 100644
--- a/src/test/test-calendarspec.c
+++ b/src/test/test-calendarspec.c
@@ -80,6 +80,7 @@ int main(int argc, char* argv[]) {
test_one(minutely, *-*-* *:*:00);
test_one(quarterly, *-01,04,07,10-01 00:00:00);
test_one(semi-annually, *-01,07-01 00:00:00);
+test_one(semesterly, *-01,07-01 00:00:00);
test_one(annually, *-01-01 00:00:00);
test_one(*:2/3, *-*-* *:02/3:00);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] man: reorganization of calendar specs
On Thu, 30.10.14 12:19, Daniele Medri (dme...@gmail.com) wrote: --- man/systemd.time.xml | 31 ++- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/man/systemd.time.xml b/man/systemd.time.xml index 2342684..2ee5858 100644 --- a/man/systemd.time.xml +++ b/man/systemd.time.xml @@ -241,23 +241,20 @@ paraTimezone names may not be specified./para -paraThe special expressions -literalminutely/literal, -literalhourly/literal, literaldaily/literal, -literalmonthly/literal, literalweekly/literal, -literalyearly/literal, -literalquarterly/literal, - literalsemesterly/literal or literalsemiannually/literal - may be used as calendar events which refer to -literal*-*-* *:*:00/literal, -literal*-*-* *:00:00/literal, -literal*-*-* 00:00:00/literal, -literal*-*-01 00:00:00/literal, -literalMon *-*-* 00:00:00/literal, -literal*-01-01 00:00:00/literal, -literal*-01,04,07,10-01 00:00:0/literal and -literal*-01,07-01 00:00:00/literal respectively. -/para +paraSpecial expressions may be used as calendar events:/para + + programlisting + minutely → *-*-* *:*:00 +hourly → *-*-* *:00:00 + daily → *-*-* 00:00:00 +weekly → Mon *-*-* 00:00:00 + monthly → *-*-01 00:00:00 + quarterly → *-01,04,07,10-01 00:00:00 +semesterly → *-01,07-01 00:00:00 + semiannually → *-01,07-01 00:00:00 +yearly → *-01-01 00:00:00 + annually → *-01-01 00:00:00 +/programlisting I'd think turning this into a proper docbook table would make a ton of sense! Would love to take a patch for that! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/5] calendar: parse months's names
On Thu, 30.10.14 12:19, Daniele Medri (dme...@gmail.com) wrote:
As mentiond in my early review, such a bitfield would duplicate the
months chain we already have in place.
I am totally onboard with allowing a syntax where month names are
used, but this really should be translated into the normal chain stuff
internally, to avoid a redundant structure in memory!
Lennart
---
man/systemd.time.xml | 9 +++
src/shared/calendarspec.c | 202
++
src/shared/calendarspec.h | 1 +
3 files changed, 212 insertions(+)
diff --git a/man/systemd.time.xml b/man/systemd.time.xml
index 2ee5858..d108871 100644
--- a/man/systemd.time.xml
+++ b/man/systemd.time.xml
@@ -225,6 +225,15 @@
range of continuous weekdays. literal,/literal and
literal-/literal may be combined freely./para
+paraThe months's names specification is available too.
+It should consist of one or more English
+language months's names, either in the abbreviated
+(Apr) or non-abbreviated (April) form (case does
+not matter), separated by commas. Specifying two
+months separated by literal-/literal refers to a
+range of continuous months. literal,/literal and
+literal-/literal may be combined freely./para
+
paraIn the date and time specifications, any
component may be specified as literal*/literal in
which case any value will match. Alternatively, each
diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 9b05f13..dea83ce 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -25,6 +25,7 @@
#include calendarspec.h
#define BITS_WEEKDAYS127
+#define BITS_MONTHS 4095/* 0^2 + 1^2 + ... + 11^2 */
static void free_chain(CalendarComponent *c) {
CalendarComponent *n;
@@ -125,6 +126,9 @@ int calendar_spec_normalize(CalendarSpec *c) {
if (c-weekdays_bits = 0 || c-weekdays_bits = BITS_WEEKDAYS)
c-weekdays_bits = -1;
+if (c-months_bits = 0 || c-months_bits = BITS_MONTHS)
+c-months_bits = -1;
+
fix_year(c-year);
sort_chain(c-year);
@@ -159,6 +163,9 @@ _pure_ bool calendar_spec_valid(CalendarSpec *c) {
if (c-weekdays_bits BITS_WEEKDAYS)
return false;
+if (c-months_bits BITS_MONTHS)
+return false;
+
if (!chain_valid(c-year, 1970, 2199))
return false;
@@ -229,6 +236,60 @@ static void format_weekdays(FILE *f, const CalendarSpec
*c) {
}
}
+static void format_months(FILE *f, const CalendarSpec *c) {
+static const char *const months[] = {
+Jan,
+Feb,
+Mar,
+Apr,
+May,
+Jun,
+Jul,
+Aug,
+Sep,
+Oct,
+Nov,
+Dec
+};
+
+int l, x;
+bool need_colon = false;
+
+assert(f);
+assert(c);
+assert(c-months_bits 0 c-months_bits = BITS_MONTHS);
+
+for (x = 0, l = -1; x (int) ELEMENTSOF(months); x++) {
+
+if (c-months_bits (1 x)) {
+
+if (l 0) {
+if (need_colon)
+fputc(',', f);
+else
+need_colon = true;
+
+fputs(months[x], f);
+l = x;
+}
+
+} else if (l = 0) {
+
+if (x l + 1) {
+fputc(x l + 2 ? '-' : ',', f);
+fputs(months[x-1], f);
+}
+
+l = -1;
+}
+}
+
+if (l = 0 x l + 1) {
+fputc(x l + 2 ? '-' : ',', f);
+fputs(months[x-1], f);
+}
+}
+
static void format_chain(FILE *f, int space, const CalendarComponent *c) {
assert(f);
@@ -266,6 +327,11 @@ int calendar_spec_to_string(const CalendarSpec *c, char
**p) {
fputc(' ', f);
}
+if (c-months_bits 0 c-months_bits = BITS_MONTHS) {
+format_months(f, c);
+fputc(' ', f);
+}
+
format_chain(f, 4, c-year);
fputc('-', f);
format_chain(f, 2, c-month);
@@ -385,6 +451,108 @@ static int parse_weekdays(const char **p, CalendarSpec
*c) {
}
}
+static int parse_months(const char **p, CalendarSpec *c) {
+static const struct {
+const
Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?
On Thu, 30.10.14 12:30, grantksupp...@operamail.com (grantksupp...@operamail.com) wrote: exec of systemctl poweroff causes, as reported, a reboot/restart but, exec of systemctl --force poweroff otoh, does shut down the machine, though not gracefully This got recently fixed in git. Please verify. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Commands started after su - username do not obey systemctl set-property user.slice MemoryLimit=...
On Wed, 29.10.14 21:08, Lutz Vieweg (l...@5t9.de) wrote: Hi, I configured a CentOS 7 to limit the amount of memory any single interactive user can use by setting: systemctl set-property user.slice MemoryLimit=60G and excepted root to use a less strict limit: systemctl set-property user-0.slice MemoryLimit=120G Works so far, but there's a catch: Some times, root wants to impersonate some user to interactively start some software on behalf of that user. Yet, when root uses su - username to change the user, no user-xxx.slice is created, not even a new session below user-0.slice is created, causing the wrong MemoryLimit to be applied: systemd-cgls └─user.slice ├─user-0.slice ... │ └─session-18.scope │ ├─17570 sshd: root@pts/1 │ ├─17572 -bash │ ├─19514 bash │ ├─19884 su - johndoe │ ├─19885 -bash │ ├─20395 ./memory_hog ... How can I configure that processes started as a certain user honor the user.slice limit, regardless of whether the user used ssh to log in, or whether just root was using su to become that user? Using su doesn't really open a new session, it really just changes the numeric UID, and very few other things. It does not create a new bus, doesn't pass access to the audio stack, does not create a new tty, no new XDG_RUNTIME_DIR or anything else. It's a mix and match you get between the old user and the new user, and part of that is that no new session is registered by logind, and hence no resources are applied. By using su you basically tell the system that you want to quickly and temporarily change your uid, but *without* doing a full new login, hence staying within your old session. Hence this is what you get... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add timesync-wait tool
On Wed, 29.10.14 17:50, Lukasz Stelmach (stl...@poczta.fm) wrote: I mean, what is the tool supposed to be waiting on: that the time is set as accurately as possible (in that case watching STA_UNSYNC sounds good, plus waiting for TFD_CANCEL_ON_SET for big jumps and guessing sleep times from adjtimex()'s return values for smaller jumps)? There is no point in guessing. Clearing STA_UNSYNC takes one timesynced cycle (32s, see below). Well, the algorithm I was envisioning there would be one which wouldn#t strictly be tied to timesycnd being the NTP server. By checking what adjtimex returns I figure we could guess when the fix is likely to be done. Or that the time is set accurately enough for adjtimex() to be used for the remaining accuracy (In that case, we'd actually have to make timesyncd report this information to us, maybe using a flag file to watch via inotify)? This is probably what satisfies most users. Or that the time set accurately enough to be monotonic, but not more (in that case just ordering after systemd-timesyncd.service should be enough, no need for any other tool)? timesyncd sends READY=1 quite early. I think it is before it tries to contact time servers. Yes. And that's really the right thing to do. In normal setups we really should not wait for external conditions. Of these three options, I think the first one is not necessarily a good idea, since adjtimex() is really about making time corrections smooth and hence slow. Making this slow, and trying to wait for it is kinda contradictory, no? Not really, that is it isn't that slow. I measured it. First I set the current time off by less than a minute then waited date $(date +%m%d%H%M%Y) sleep 2 time ./systemd-timesync-wait and it always took one timesyncd cycle (32 seconds) to clear STA_UNSYNC. How about waiting for either a flag-file which timesyncd creates after a few seconds timesynced is started or, if a user chooses so, for the real synchronisation? The third one is not a good idea either, since we already have functionality covering that. But if the second option is the relevant one, then I figure neither adjtimex() nor TFP_CANCEL_ON_SET will be useful to us, and instead we need to teach systemd-timesyncd some flag file stuff. Yes, like hey I've already received the time from an NTP server and fed it to the kernel. Create /run/systemd/timesyncd/synchronised here: http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=v217#n389 Correct. and unlink it here http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=v217#n293 Sure? (see below) and of upon exit. An erroneous one too. Hmm, why remove it on exit or on time change? I mean, I figure this really should be a one-time thing: a way how the tool can wait until the first sync is acquired, and that's it. The same way as network-wait-online has a timeout this tool should probably have one too. If the timeout is reached the tool exits with a non-zero code. Right? That makes sense. Is three minutes OK? I'd use the same default timeout as for systemd-network-wait-online, for whatever that is. Are you sure there is a timeout? The service type is oneshot (timeout is disabled according to systemd.service(5)) without any Timeout* set. Two calls to sd_event_exit() in the code depend manager_all_configured() and no sign of any timer. Indeed. It really should have one though. Added to TODO list now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?
On Mon, Nov 10, 2014, at 04:07 PM, Lennart Poettering wrote: On Thu, 30.10.14 12:30, grantksupp...@operamail.com (grantksupp...@operamail.com) wrote: exec of systemctl poweroff causes, as reported, a reboot/restart but, exec of systemctl --force poweroff otoh, does shut down the machine, though not gracefully This got recently fixed in git. Please verify. I'm a bit confused. In #systemd, I'd been told that this was not relevant to my specific issue, and that the problem was solely with my distro. So, here's where I've been discussing it: Bug 903560 - opensuse 13.1 ( + Kernel:Stable 3.17.2 + systemd 210) exec of `shutdown` restarts machine instead https://bugzilla.suse.com/show_bug.cgi?id=903560#c40 Is the fixed-in-git you are referencing relevant to the issue with systemd discussed at opensuse? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
Lennart Poettering lenn...@poettering.net writes: On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote: Please boot with systemd.log_level=debug, then make the machine hang and check what the last things in the logs say. Maybe then paste that somewhere online and post the URL for that here, so that we can have a look. Here's the output (obtained by changing log level and remounting earlier in the debug.sh script): https://dl.dropboxusercontent.com/u/11545826/shutdown.log Thanks for your help! Hmm the logs show that systemd pretty much completed its shutdown. After the message Cannot finalize remaining DM devices, continuing. the only thing that still runs is the shutdown hooks you used to generate this log, plus either a jump back into your initrd (if your initrd supports that) or the reboot() system call. If the latter hangs then it's a kernel bug. reboot -f works fine - could it still be a kernel bug? Please check if there are any other scripts in /lib/systemd/system-shutdown/ that might be at fault here. Nope, none. Please check if your initrd is one of those which support jumping back into the initrd on shutdown. For that check if /run/initramfs/shutdown exists during runtime and is executable. No, /run/initramfs/shutdown does not exist. If so, it's probably an initrd problem, please file a bug against your initrd implementation. You appear to be using LVM, I wouldn't be surprised if LVM is broken here, but I cannot help you debugging this, please contact the LVM maintainers in this case. Is there some indication that LVN is at fault? As I said in my first email, the crucial difference seems to be if an X11 console is active or not: * If I execute systemctl reboot while a text console is active, everything works fine. * If I execute systemctl reboot while the X11 console is active, the system hangs (I tried waiting up to 7 minutes). Furthermore, I am unable to switch to another console with Ctrl+Alt+Fn, the computer becomes unresponsive to the keyboard and the monitor powers down. On which tty/pty systemctl itself is executed does not matter (I tested this by running systemctl in an ssh session from a remote system), it only matters which console is currently active. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?
On Mon, Nov 10, 2014 at 04:22:42PM -0800, grantksupp...@operamail.com wrote: On Mon, Nov 10, 2014, at 04:07 PM, Lennart Poettering wrote: On Thu, 30.10.14 12:30, grantksupp...@operamail.com (grantksupp...@operamail.com) wrote: exec of systemctl poweroff causes, as reported, a reboot/restart but, exec of systemctl --force poweroff otoh, does shut down the machine, though not gracefully This got recently fixed in git. Please verify. I'm a bit confused. In #systemd, I'd been told that this was not relevant to my specific issue, and that the problem was solely with my distro. So, here's where I've been discussing it: Bug 903560 - opensuse 13.1 ( + Kernel:Stable 3.17.2 + systemd 210) exec of `shutdown` restarts machine instead https://bugzilla.suse.com/show_bug.cgi?id=903560#c40 Is the fixed-in-git you are referencing relevant to the issue with systemd discussed at opensuse? Unlikely, since that bug was introduced after 216. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Mon, Nov 10, 2014 at 10:53:46PM +0100, Lennart Poettering wrote: On Thu, 06.11.14 14:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Nov 06, 2014 at 02:28:12PM +0100, Lennart Poettering wrote: On Thu, 06.11.14 12:45, Patrick Häcker (pa...@web.de) wrote: However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? At least unattended-upgrades from Debian/Ubuntu/... can be configured to install updates on shutdown (without any special mode or something). And, yes, this can run for more than 30 minutes, which I could already observe in its default mode (installing during normal system activities), so I see no reason why this should not happen when configured to install during shutdown. The reason is, that unattended-upgrades can basically update the whole distribution to the next version, which naturally can take a lot of time. It's questionable if this is a sane setup, but I can think of setups where this might be useful, e.g. having two identically configured servers for redundancy reasons where one server would be enough. Then it might make sense to update one system during shutdown while the other one takes over. This has the advantage, that normally running servers either have the old or the new state, but never some intermediate state during the update. The shutdown time does not really matter in this case and a watchdog killing the system wouldn't be welcome. But all in all this seems like an exotic use case. Is unattended-upgrades a package of its own? If so, I'd probably ask the packagers to include drop-ins for reboot.target to override the timeout. That way, as soon as you install it the shutdown timeouts are disabled. That is suboptimal. There really should be a way to this dynamically, like saying: I'm a log-running job, I need more time, but everything is still fine. This type of status should require periodical pings, watchdog style. Let's say that the backup job run during shutdown hangs because there's no network, we want to shutdown at some point anyway. So, we always had per-unit timeouts in place, and they are opt-out (with the exception of Type=oneshot services where they are opt-in). Hence adding a second level of opt-out timeouts doesn't sound particularly attractive to me. Agreed. The reason I added the system-wide startup/shutdown timeouts was really to be a safety net, so that the individual per-unit timeouts and the opted-out exceptions don't add up beyond bounds. I guess that this is part of the issue: it is hard to define what without bounds means. A fsck, selinux relabel, package installation and probably many other things are effectively unbounded. And they might happen together at the same boot. So any kind of fixed limit is unlikely to work in the general case. [snip Yoga case] Sure, it solves this specific problem, but it causes significant problems in other configurations. It seems that we're trying to solve the problem in the wrong place. Even with the current JobTimeout configured for basic.target there's a big window of opportunity for the system to hang before systemd-logind.service is started. systemd-logind.service has After=nss-user-lookup.target, and I can image things going wrong there, especially with custom configurations. It would be nice if the guard we put in place would cover this too. Now, the question is what we can do now about this: a) we could move logind into early boot. This has multiple problems though: it would need to track system state as gettys on other ttys should only be started in multi-user mode, not in early boot. Also, the behaviour would probably not be ideal: i think it would be preferable if the system shuts down rather then suspend if we hang during boot. b) specifically do something about LUKS prompt timeouts: when a very long timeout is hit for essential devices we could simply turn off the machine again. This would fix my immediate problem, but I am not sure I like it too much, I think other hangs should really be covered too... c) we can come up with a scheme that explicitly excludes fsck, selinux relabel and so on from the overall-timeout. Sounds messy and non-obvious given that they all have individual timeouts anyway... Two layers of opting out of timeouts sounds suspicious? No good ideas so far. But whatever we do, I think we should treat portable and non-portable devices differently. The trade-offs are simply different. Otherwise, we could simply make this opt-in. After all the designing the
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On 11/11/2014 04:10 AM, Lennart Poettering wrote: On Tue, 11.11.14 00:43, WaLyong Cho (walyong@samsung.com) wrote: On 11/10/2014 10:26 PM, Lennart Poettering wrote: On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote: Calling it SmackLabel= instead of SmackLabelExec= would be fine as far as I'm concerned. SmackLabel= is more consistent with SELinuxContext= and AppArmorProfile=, as you point out. OK! WaLyong, let's name it SmackLabel= then! I think I had made you to bother. Excuse me, but I'm asking you again. And I think introducing new config should be careful. Hmm, I'm still confusing. We're already using SmackLabel= as socket config item. Yeah, it can possible as both exec/socket config. But each purposes are different. In socket config, this config is used to set SMACK64 of socket file. In exec config, this config is used to set child systemd attribute when User= config is given. And does we have to explain each man page? Or drop from socket package and move that to exec page? I'm not sure it make sense. Hmm, OK, so you might actually have a point. And this is because .socket units may carry ExecStartPre= command lines which are execute before we start listening to a socket. If we'd just have SmackLabel= then it would not be clear whether it applies as file system label to the socket fds, or if it applies as process label to the ExecStartPre= processes. Hmm, I guess I am fine with SmackLabelExec= then! Hmm, I'd thouth about this again. The name SmackLabelExec= can be shown as the value will be set to the target processes what will be executed by child systemd. But acctually the label only be used to access the executable file. I think just read the SMACK64 of the executable file and set child systemd itself will reduce our naming pain. But Casey said it way is sneaky. How do you think? WaLyong Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
