Re: [systemd-devel] [PATCH 1/2] udev: use "bit" as unit for network card speeds
On Tuesday 2013-11-12 06:34, David Timothy Strauss wrote: >On Tue, Nov 12, 2013 at 3:27 PM, Jan Engelhardt wrote: > As far as I can see, ethtool-util.c in systemd merely passes > that on to > ethtool, and /usr/include/linux/ethtool.h says "MBps" in its > comments. > > >The capitalized "B" is generally "bytes." Perhaps, but then you would still have to explain how you would encode fraction in "12.5" MBytes/s into the the unsigned ints that are used in all places. In any case, even if the ethtool structures awkwardly specified the use of "bytes", the user-visible part should be in "bits", and this patch was to give an impetus. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use "bit" as unit for network card speeds
On Tue, Nov 12, 2013 at 3:27 PM, Jan Engelhardt wrote: > As far as I can see, ethtool-util.c in systemd merely passes that on to > ethtool, and /usr/include/linux/ethtool.h says "MBps" in its comments. > The capitalized "B" is generally "bytes." ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use "bit" as unit for network card speeds
On Tuesday 2013-11-12 06:00, David Timothy Strauss wrote: >Is the code already assuming megabits in the "speed" variable? > As far as I can see, ethtool-util.c in systemd merely passes that on to ethtool, and /usr/include/linux/ethtool.h says "MBps" in its comments. What I missed is some more places in ethtool-util.c where systemd sources say "MBytes". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use "bit" as unit for network card speeds
Is the code already assuming megabits in the "speed" variable? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] udev: use "bit" as unit for network card speeds
Given a card that can do 100 Mbit/s, that would be about 12.5 MByte/s, but you cannot seriously expect me to use that value. Although it is quite compelling for 40 Gbit/s because that divides nicely to 5 GByte/sec, and we will be seeing increasing speeds :) --- man/udev.xml | 4 ++-- src/udev/net/link-config-gperf.gperf | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/udev.xml b/man/udev.xml index d157b8c..d0998ce 100644 --- a/man/udev.xml +++ b/man/udev.xml @@ -891,9 +891,9 @@ - SpeedMBytes + SpeedMBit -The speed to set for the device. +The speed to set for the device, in megabits per second. diff --git a/src/udev/net/link-config-gperf.gperf b/src/udev/net/link-config-gperf.gperf index 1fe0b93..bfb91f4 100644 --- a/src/udev/net/link-config-gperf.gperf +++ b/src/udev/net/link-config-gperf.gperf @@ -26,6 +26,6 @@ Link.MACAddress,config_parse_hwaddr, 0, offsetof(link Link.NamePolicy,config_parse_name_policy, 0, offsetof(link_config, name_policy) Link.Name, config_parse_ifname,0, offsetof(link_config, name) Link.MTU, config_parse_unsigned, 0, offsetof(link_config, mtu) -Link.SpeedMBytes, config_parse_unsigned, 0, offsetof(link_config, speed) +Link.SpeedMBit, config_parse_unsigned, 0, offsetof(link_config, speed) Link.Duplex,config_parse_duplex,0, offsetof(link_config, duplex) Link.WakeOnLan, config_parse_wol, 0, offsetof(link_config, wol) -- 1.8.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] man: wording and grammar updates
This is a recurring submission and includes corrections to various issue spotted: comma setting, missing words/preposition choice. Important this time: /lib was changed to /usr/lib, since that is what most distros seem to use for their systemd/udev file location. --- man/sd_is_fifo.xml | 2 +- man/systemd-networkd.service.xml | 8 man/udev.xml | 12 ++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/man/sd_is_fifo.xml b/man/sd_is_fifo.xml index 4d9cd79..ec109a9 100644 --- a/man/sd_is_fifo.xml +++ b/man/sd_is_fifo.xml @@ -165,7 +165,7 @@ called to check whether the specified file descriptor refers to a special file. If the path parameter is not -NULL, it is checked whether file +NULL, it is checked whether the file descriptor is bound to the specified file name. Special files in this context are character device nodes and files in /proc diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml index 209e3be..db23978 100644 --- a/man/systemd-networkd.service.xml +++ b/man/systemd-networkd.service.xml @@ -66,8 +66,8 @@ Network configurations applied before networkd is started are not removed, and configuration applied by networkd are not removed when networkd exits. This ensures restarting networkd -does not cut the network connection, and in particular that it -is safe to transition between the initrd and the real root, +does not cut the network connection, and, in particular, that +it is safe to transition between the initrd and the real root, and back. @@ -82,10 +82,10 @@ identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence over files with the same -name in /lib. This can be used to override a +name in /usr/lib. This can be used to override a system-supplied network file with a local file if needed; a symlink in /etc with the same name as a network file in -/lib, pointing to /dev/null, +/usr/lib, pointing to /dev/null, disables the network file entirely. Network files must have the extension .network; other extensions are ignored. diff --git a/man/udev.xml b/man/udev.xml index d0998ce..56d650b 100644 --- a/man/udev.xml +++ b/man/udev.xml @@ -63,10 +63,10 @@ regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence - over files with the same name in /lib. This can be + over files with the same name in /usr/lib. This can be used to override a system-supplied rules file with a local file if needed; a symlink in /etc with the same name as a rules file in - /lib, pointing to /dev/null, + /usr/lib, pointing to /dev/null, disables the rules file entirely. Rule files must have the extension .rules; other extensions are ignored. @@ -715,10 +715,10 @@ regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence - over files with the same name in /lib. This can be + over files with the same name in /usr/lib. This can be used to override a system-supplied hwdb file with a local file if needed; a symlink in /etc with the same name as a hwdb file in - /lib, pointing to /dev/null, + /usr/lib, pointing to /dev/null, disables the hwdb file entirely. hwdb files must have the extension .hwdb; other extensions are ignored. @@ -754,10 +754,10 @@ regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence - over files with the same name in /lib. This can be + over files with the same name in /usr/lib. This can be used to override a system-supplied link file with a local file if needed; a symlink in /etc with the same name as a link file in - /lib, pointing to /dev/null, + /usr/lib, pointing to /dev/null, disables the link file entirely. The link file contains a [Match] section, which -- 1.8.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] missing files from commit? bus-dump.[ch]
On Tue, Nov 12, 2013 at 10:36 AM, Peeters Simon wrote: > in 2b5c5383 you reference src/libsystemd-bus/bus-dump.c and > src/libsystemd-bus/bus-dump.c , but those files aren't included, could > you please commit them asap? > I've already emailed him. In the mean time, you can use one of the earlier hashes. My CI box also only mirrors to GitHub on successful builds and tests. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help with a systemd/mdadm interaction.
On Tuesday 2013-11-12 01:31, NeilBrown wrote: > >mdadm is quite good at assembling arrays incrementally. "udev" runs >"mdadm -I" for each new device and mdadm gathers them into arrays and >activates the array once all the expected devices have been gathered. >[mdadm might] wait [...] forever. >mdadm can handle this, but it needs to be told. The command: > mdadm -IRs >will find any arrays which have enough devices to start degraded but haven't >been started yet, and will start them. Using mdadm -R in udev would be a really bad idea, because it would make for a race, I think. Consider a system that has finished booting and is as ready as can be, and you plug in USB disks that form a RAID array. If you use -R, the array may start before you had the chance to plug them all in, causing the array to start in degraded mode, potentially causing a long resync when all missing devices have been plugged into their sockets. >Alternately, is there some "all devices have been probed, nothing new will >appear unless it is hot-plugged" event. That would be equally useful (and >probably mirrors what hardware-RAID cards do). IIRC, openSUSE had a /etc/init.d/boot.coldplug once upon a time (seems to be 9.3) that acted like what you describe. The order was like udevadm trigger, load static module list, udevadm settle, run mdadm, chroot /realroot, repeat for real root once more. Would that still work? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] missing files from commit? bus-dump.[ch]
lennart, in 2b5c5383 you reference src/libsystemd-bus/bus-dump.c and src/libsystemd-bus/bus-dump.c , but those files aren't included, could you please commit them asap? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Need help with a systemd/mdadm interaction.
Hi, I wonder if I could get some advice mdadm is quite good at assembling arrays incrementally. "udev" runs "mdadm -I" for each new device and mdadm gathers them into arrays and activates the array once all the expected devices have been gathered. This simple rule falls down if some expected device doesn't appear. If an array is marked as degraded then mdadm doesn't expect the missing device and will happily start the degaded array. However if the system shuts down with the md array fully functional, and a device is removed before the system is restarted, then mdadm does not know that the device is missing and will effectively wait for it forever. mdadm can handle this, but it needs to be told. The command: mdadm -IRs will find any arrays which have enough devices to start degraded but haven't been started yet, and will start them. I used this quite effectively in out initrd. There is a loop that count up to N waiting for the root device to appear and when we get to "N/2" I run "mdadm -IRs" which makes any newly-degraded arrays appear. I'm wondering how to integrate this with systemd. Systemd has its own mechanism to wait for devices to appear, but I cannot see anyway to run "mdadm -IRs" at the half-way mark. It would of course be sufficient to wait for the complete timeout, then run "mdadm -IRs", then check if the device has appeared, but I can't see how to fit this into systemd either. So: how can I fit this need for "run some command on device timeout which might be successful in activating the device"? Alternately, is there some "all devices have been probed, nothing new will appear unless it is hot-plugged" event. That would be equally useful (and probably mirrors what hardware-RAID cards do). Thanks, NeilBrown signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuration file parser library
On Mon, Nov 11, 2013 at 4:09 PM, Mantas Mikulėnas wrote: > On Mon, Nov 11, 2013 at 10:29 PM, Chris Morgan wrote: >> I don't see that GKeyFile supports nested groups. For my users I was >> hoping to present something like: >> >> [Clients] >> >> [ObjectNameHere] >> type='value' >> >>[AnotherObjectHere] >>type='value' >> >> [Services] >> [ObjectNameHere] >> ... >> >> >> >> with the hope that on the parsing side I could iterate over the >> entries under 'Services' and then repeat under 'Clients'. > > No, INI does not work that way – it is not hierarchical. (Leading > spaces are almost always ignored.) > > Git uses [foo "bar"] to implement two-level hierarchy. GNOME dconf > uses [foo/bar/baz] when exporting hierarchical configuration; sssd's > configuration is simpler, but it still has [foo/bar] in some places. > Similarly, Windows .reg files – exported Registry branches – use > [foo\bar\baz]. > > -- > Mantas Mikulėnas Ahh. But: [service.SomeService] key=value [client.SomeClient] key=value works? It would be fine to search through for things that started with 'service.' or 'client.' as a convention. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuration file parser library
On Mon, Nov 11, 2013 at 10:29 PM, Chris Morgan wrote: > I don't see that GKeyFile supports nested groups. For my users I was > hoping to present something like: > > [Clients] > > [ObjectNameHere] > type='value' > >[AnotherObjectHere] >type='value' > > [Services] > [ObjectNameHere] > ... > > > > with the hope that on the parsing side I could iterate over the > entries under 'Services' and then repeat under 'Clients'. No, INI does not work that way – it is not hierarchical. (Leading spaces are almost always ignored.) Git uses [foo "bar"] to implement two-level hierarchy. GNOME dconf uses [foo/bar/baz] when exporting hierarchical configuration; sssd's configuration is simpler, but it still has [foo/bar] in some places. Similarly, Windows .reg files – exported Registry branches – use [foo\bar\baz]. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuration file parser library
On Sun, Nov 10, 2013 at 4:54 PM, Lennart Poettering wrote: > On Sat, 09.11.13 09:02, Chris Morgan (chmor...@gmail.com) wrote: > >> Hello. >> >> I wanted to implement a configuration file format for an application of >> mine that uses a similar format to what systemd uses. I was wondering if >> the parser used today was from an external library. I googled a bit but >> wasn't able to dig anything up. I haven't looked at the code in detail yet. > > We use our homegrown code for parsing configuration files. It's fancier > these days than it used to be (even using gperf perfect hash tables for > key lookup), but it's nothing I'd ever want to see used outside of our > specific domain of low-level system components. > > Use GLib's GKeyFile in other projects. We try to stay compatible with > it, however only in one way, i.e. so that GKeyFile can be used to write > configuration files for systemd and has access to all features of > systemd, however, not all systemd configuration files can be read by > GKeyFile. (the reason for that is mostly that we allow multiple > assignments to the same key, which GKeyFile (currently) doesn't allow, > and more suggests pushing a serialization of multiple assignments into > the same line, which is really difficult to read though as we believe, > and systemd runs into this quite often). > > Lennart > > -- > Lennart Poettering, Red Hat To keep it short: I don't see that GKeyFile supports nested groups. For my users I was hoping to present something like: [Clients] [ObjectNameHere] type='value' [AnotherObjectHere] type='value' [Services] [ObjectNameHere] ... with the hope that on the parsing side I could iterate over the entries under 'Services' and then repeat under 'Clients'. I *could* put a key under each entry to define whether it is a client or a service but this seemed less naturally ordered. Anyway, this is off-topic for systemd, I've gotten several good responses here and I appreciate it. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuration file parser library
On Monday 2013-11-11 07:21, Anatol Pomozov wrote: >Hi > >On Sat, Nov 9, 2013 at 6:02 AM, Chris Morgan wrote: >> Hello. >> >> I wanted to implement a configuration file format for an application of mine >> that uses a similar format to what systemd uses. I was wondering if the >> parser used today was from an external library. I googled a bit but wasn't >> able to dig anything up. I haven't looked at the code in detail yet. > >INIH is a great small project for parsing .ini files > >https://code.google.com/p/inih/ Funny how that almost reads "i-NIH". And then there is libiniparser that's used by the samba camp, and then there is also libini_config from ding-libs used by the sssd camp... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Path unit configuration starts early (DefaultDependencies=no)
On Mon, Nov 11, 2013 at 05:50:51PM +0100, Abdelghani Ouchabane wrote: > On 11/11/13 17:35, Zbigniew Jędrzejewski-Szmek wrote: > >On Mon, Nov 11, 2013 at 05:26:28PM +0100, Abdelghani Ouchabane wrote: > >>Hallo, > >> I have two configuration files: ezono-cyclades-t_upn.path & > >>ezono-cyclades-t_upn.service > >> > >> > >>Where: > >> > >>ezono-cyclades-t_upn.path : > >> > >>[Unit] > >>Description=ezono-cyclades-t_upn Service Spool > >>DefaultDependencies=no > >>Conflicts=shutdown.target > >>Before=shutdown.target > >> > >>[Path] > >>PathExists=/tmp/cyclades/start-ezono-cyclades-gui > >> > >>[Install] > >>WantedBy=ezono-cyclades.target > >> > >> > >>The problem is that by passing "DefaultDependencies=no" > >>ezono-cyclades-t_upn.service doesn't start after > >>/tmp/cyclades/start-ezono-cyclades-gui is created, even after all > >>other units run and I delete /tmp/cyclades/start-ezono-cyclades-gui > >>and create it again. > >> > >>Any idea please. > >Is ezono-cyclaed.target enabled? > Yes > > ezono-cyclades.target - eZono Cyclades GUI >Loaded: loaded (/usr/lib/systemd/system/ezono-cyclades.target; enabled) >Active: active since Mon 2013-11-11 17:48:43 CET; 23s ago > > Nov 11 17:48:43 sonostation-usb12-eth.ezono.net systemd[1]: Starting > eZono Cyclades GUI. > Nov 11 17:48:43 sonostation-usb12-eth.ezono.net systemd[1]: Reached > target eZono Cyclades GUI. The condition is only checked once, when the unit is started. I'd guess that whatever creates /tmp/cyclades/start-ezono-cyclades-gui, does it after the ezono-cyclades-t_upn.service/start job has already been done. The condition will not be checked again unless you restart the servcie. > >Also, DefaultDependencies=no is very unlikely to be what you need. > I want to start ezono-cyclades-t_upn.path early as I can That's not very convicing. I have no idea what it does, but DefaultDependencies=no is only appropriate for services which participate in bringing up the system. Units that you show are very very complex, but it's unlikely that this is all needed. E.g. don't implement your own strange logging solutions, just start systemd with --log-level=debug and you'll get full information about what is started and when. Also output from services is logged to the journal by default. > >Also, /tmp/cyclades is subject to "predicatable paths in /tmp" attack. > >You should use a file in /run/. > > > >Zbyszek > Thanks Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] zsh-completion: Function declarations follow style
Follow the instructions in CODING_STYLE for the zsh completion
functions.
---
shell-completion/zsh/_hostnamectl | 3 ++-
shell-completion/zsh/_journalctl | 12
shell-completion/zsh/_kernel-install | 6 --
shell-completion/zsh/_localectl | 12
shell-completion/zsh/_sd_machines | 3 ++-
shell-completion/zsh/_systemctl | 9 ++---
shell-completion/zsh/_systemd-analyze | 6 --
shell-completion/zsh/_systemd-coredumpctl | 3 ++-
shell-completion/zsh/_systemd-delta | 3 ++-
shell-completion/zsh/_systemd-inhibit | 6 --
shell-completion/zsh/_systemd-nspawn | 3 ++-
shell-completion/zsh/_systemd-run | 9 ++---
shell-completion/zsh/_timedatectl | 15 ++-
shell-completion/zsh/_udevadm | 27 ++-
14 files changed, 78 insertions(+), 39 deletions(-)
diff --git a/shell-completion/zsh/_hostnamectl
b/shell-completion/zsh/_hostnamectl
index 7d7baeb..c7a5ec0 100644
--- a/shell-completion/zsh/_hostnamectl
+++ b/shell-completion/zsh/_hostnamectl
@@ -1,6 +1,7 @@
#compdef hostnamectl
-_hostnamectl_command() {
+_hostnamectl_command()
+{
local -a _hostnamectl_cmds
_hostnamectl_cmds=(
"status:Show current hostname settings"
diff --git a/shell-completion/zsh/_journalctl b/shell-completion/zsh/_journalctl
index b518e35..fcb7874 100644
--- a/shell-completion/zsh/_journalctl
+++ b/shell-completion/zsh/_journalctl
@@ -1,6 +1,7 @@
#compdef journalctl
-_list_fields() {
+_list_fields()
+{
local -a journal_fields
journal_fields=(MESSAGE{,_ID} PRIORITY CODE_{FILE,LINE,FUNC}
ERRNO SYSLOG_{FACILITY,IDENTIFIER,PID}
@@ -20,7 +21,8 @@ _list_fields() {
esac
}
-_journal_none() {
+_journal_none()
+{
local -a _commands _files _jrnl_none
# Setting use-cache will slow this down considerably
_commands=( ${"$(_call_program commands "$service" -F _EXE
2>/dev/null)"} )
@@ -31,7 +33,8 @@ _journal_none() {
'fields:fields:_list_fields'
}
-_journal_fields() {
+_journal_fields()
+{
local -a _fields cmd
cmd=("journalctl" "-F ${@[-1]}" "2>/dev/null" )
_fields=( ${(f)"$(_call_program fields $cmd[@])"} )
@@ -39,7 +42,8 @@ _journal_fields() {
_describe 'possible values' _fields
}
-_journal_boots() {
+_journal_boots()
+{
local -a _bootid _previousboots
_bootid=( ${(fao)"$(_call_program bootid "$service -F _BOOT_ID")"} )
_previousboots=( -{1..${#_bootid}} )
diff --git a/shell-completion/zsh/_kernel-install
b/shell-completion/zsh/_kernel-install
index 3bc29fd..2f1adb5 100644
--- a/shell-completion/zsh/_kernel-install
+++ b/shell-completion/zsh/_kernel-install
@@ -1,6 +1,7 @@
#compdef kernel-install
-_images(){
+_images()
+{
if [[ "$words[2]" == "remove" ]]; then
_message 'No more options'
else
@@ -8,7 +9,8 @@ _images(){
fi
}
-_kernels(){
+_kernels()
+{
read _MACHINE_ID < /etc/machine-id
_kernel=( /lib/modules/[0-9]* )
if [[ "$cmd" == "remove" && -n "$_MACHINE_ID" ]]; then
diff --git a/shell-completion/zsh/_localectl b/shell-completion/zsh/_localectl
index 1e3cf03..b94c9d3 100644
--- a/shell-completion/zsh/_localectl
+++ b/shell-completion/zsh/_localectl
@@ -1,6 +1,7 @@
#compdef localectl
-_localectl_set-locale() {
+_localectl_set-locale()
+{
local -a _confs _locales
local expl suf
_locales=( ${(f)"$(_call_program locales "$service" list-locales)"} )
@@ -15,7 +16,8 @@ _localectl_set-locale() {
fi
}
-_localectl_set-keymap() {
+_localectl_set-keymap()
+{
local -a _keymaps
_keymaps=( ${(f)"$(_call_program locales "$service" list-keymaps)"} )
if (( CURRENT <= 3 )); then
@@ -25,7 +27,8 @@ _localectl_set-keymap() {
fi
}
-_localectl_set-x11-keymap() {
+_localectl_set-x11-keymap()
+{
if (( $+commands[pkg-config] )); then
local -a _file _layout _model _variant _options
local _xorg_lst
@@ -50,7 +53,8 @@ _localectl_set-x11-keymap() {
fi
}
-_localectl_command() {
+_localectl_command()
+{
local -a _localectl_cmds
_localectl_cmds=(
'status:Show current locale settings'
diff --git a/shell-completion/zsh/_sd_machines
b/shell-completion/zsh/_sd_machines
index df2f462..e2e5c04 100644
--- a/shell-completion/zsh/_sd_machines
+++ b/shell-completion/zsh/_sd_machines
@@ -1,5 +1,6 @@
#autoload
-__get_machines () {
+__get_machines()
+{
machinectl --full --no-pager list | {while read -r a b; do echo $a;
done;};
}
diff --git a/shell-completion/zsh/_systemctl b/shell-completion/zsh/_systemctl
index 133a550..1ab66ce 100644
--- a/shell-completion/zsh/_systemctl
+++ b/shell-completion/zsh/_systemctl
@@ -121,7 +121,8 @@ _systemctl_really_all_units()
[systemd-devel] [PATCH 0/2] zsh-completion style fixes
Just style changes to the zsh completion. If either of these patches are too large, you can view them at http://git.kaictl.net/wgiokas/systemd.git/?h=zsh-stylefix William Giokas (2): zsh-completion: Use same tab-width for all files zsh-completion: Function declarations follow style shell-completion/zsh/_hostnamectl | 52 +-- shell-completion/zsh/_journalctl | 169 - shell-completion/zsh/_kernel-install | 38 +- shell-completion/zsh/_localectl| 143 shell-completion/zsh/_loginctl | 133 +++ shell-completion/zsh/_machinectl | 71 ++-- shell-completion/zsh/_sd_hosts_or_user_at_host | 5 +- shell-completion/zsh/_sd_machines | 4 +- shell-completion/zsh/_sd_outputmodes | 1 + shell-completion/zsh/_systemctl| 466 + shell-completion/zsh/_systemd | 154 shell-completion/zsh/_systemd-analyze | 71 ++-- shell-completion/zsh/_systemd-coredumpctl | 60 ++-- shell-completion/zsh/_systemd-delta| 22 +- shell-completion/zsh/_systemd-inhibit | 53 +-- shell-completion/zsh/_systemd-nspawn | 40 ++- shell-completion/zsh/_systemd-run | 10 +- shell-completion/zsh/_systemd-tmpfiles | 15 +- shell-completion/zsh/_timedatectl | 106 +++--- shell-completion/zsh/_udevadm | 234 +++-- 20 files changed, 952 insertions(+), 895 deletions(-) -- 1.8.5.rc0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd + ExecStart + python script
On 11/11/13 17:32, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Nov 11, 2013 at 04:55:05PM +0100, Abdelghani Ouchabane wrote: ExecStart=/usr/bin/python /opt/cyclades/bin/t_idl.pyo |-1377 /bin/sh -c if [ ! -e /home/x/taskconfig/screensaver ]; then /bin/mkdir -p /home/x/taskconfig ;/bin/cp /opt/cyclades/etc/taskconfig/screensaver /home/x/taskconfig/screensaver ;fi ; /bin/echo -n $BASHPID > /var/tmp/cyclades_services/IDL/pid ; DISPLAY=:0 CYCLADES_ERR=IDL /opt/cyclades/bin/logger.sh -c "/usr/bin/python /opt/cyclades/bin/t_idl.pyo" -p err -t IDL Those two don't correspond. Either you're starting the program directly, or through some shell scripts. It would help if you showed the two unit files. Zbyszek Hi Zbyszek, thanks a lot for your quick replay. I am sorry that I send a modified script. Well here is the right one: Regards ezono-cyclades-t_idl.service: .include /usr/lib/systemd/system/ezono-cyclades-user-x-settings.service [Unit] Description=ezono-cyclades-t_idl Service Conflicts=ezono-cyclades-emergency-stop.service ezono-cyclades-stop-tasks.service ConditionPathExists=!/tmp/emergency ConditionPathExists=|/opt/cyclades/etc/end-user ConditionPathExists=|/opt/cyclades/etc/development-system [Service] Type=simple WorkingDirectory=/tmp SuccessExitStatus=0 #Set the configuration file ExecStartPre=/bin/sh -c 'if [ ! -e /home/x/taskconfig/screensaver ]; then \ /bin/mkdir -p /home/x/taskconfig ; \ /bin/cp /opt/cyclades/etc/taskconfig/screensaver /home/x/taskconfig/screensaver ; \ fi' ExecStartPre=/bin/echo -n $BASHPID > /var/tmp/cyclades_services/IDL/pid ExecStart=/bin/sh -c 'DISPLAY=:0 CYCLADES_ERR=IDL /opt/cyclades/bin/logger.sh -c \"/usr/bin/python /opt/cyclades/bin/t_idl.pyo\" -p err -t IDL' ExecStop=/bin/sh -c '[ ! -f /opt/cyclades/etc/systemd-debug ] || logger -p local4.debug -t SYSTEMD Unit IDL stopping...' ExecStop=/bin/touch /tmp/cyclades/stoptask.IDL ExecStopPost=/bin/sh -c '[ ! -f /opt/cyclades/etc/systemd-debug ] || logger -p local4.debug -t SYSTEMD Unit IDL stopped' Restart=on-failure #RestartSec=1 TimeoutStopSec=30 #Limit restarting to 2 times in 30 seconds StartLimitBurst=2 StartLimitInterval=30 Logs: [root@sonostation-usb12-eth system]# systemctl status ezono-cyclades-t_idl.service ezono-cyclades-t_idl.service - ezono-cyclades-t_idl Service Loaded: loaded (/usr/lib/systemd/system/ezono-cyclades-t_idl.service; static) Active: active (running) since Mon 2013-11-11 17:42:57 CET; 2min 3s ago Process: 1562 ExecStartPre=/bin/echo -n $BASHPID > /var/tmp/cyclades_services/IDL/pid (code=exited, status=0/SUCCESS) Process: 1512 ExecStartPre=/bin/sh -c if [ ! -e /home/x/taskconfig/screensaver ]; then /bin/mkdir -p /home/x/taskconfig ; /bin/cp /opt/cyclades/etc/taskconfig/screensaver /home/x/taskconfig/screensaver ; fi (code=exited, status=0/SUCCESS) Main PID: 1590 (sh) CGroup: name=systemd:/system/ezono-cyclades-t_idl.service |-1590 /bin/sh -c DISPLAY=:0 CYCLADES_ERR=IDL /opt/cyclades/bin/logger.sh -c "/usr/bin/python /opt/cyclades/bin/t_idl.pyo" -p ... |-1642 /usr/bin/python /opt/cyclades/bin/t_idl.pyo `-1643 logger -p local4.err -t IDL -- Nov 11 17:43:02 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:03 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:03 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:05 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:05 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:05 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:07 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:09 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:21 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 17:43:24 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Path unit configuration starts early (DefaultDependencies=no)
On 11/11/13 17:35, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Nov 11, 2013 at 05:26:28PM +0100, Abdelghani Ouchabane wrote: Hallo, I have two configuration files: ezono-cyclades-t_upn.path & ezono-cyclades-t_upn.service Where: ezono-cyclades-t_upn.path : [Unit] Description=ezono-cyclades-t_upn Service Spool DefaultDependencies=no Conflicts=shutdown.target Before=shutdown.target [Path] PathExists=/tmp/cyclades/start-ezono-cyclades-gui [Install] WantedBy=ezono-cyclades.target The problem is that by passing "DefaultDependencies=no" ezono-cyclades-t_upn.service doesn't start after /tmp/cyclades/start-ezono-cyclades-gui is created, even after all other units run and I delete /tmp/cyclades/start-ezono-cyclades-gui and create it again. Any idea please. Is ezono-cyclaed.target enabled? Yes ezono-cyclades.target - eZono Cyclades GUI Loaded: loaded (/usr/lib/systemd/system/ezono-cyclades.target; enabled) Active: active since Mon 2013-11-11 17:48:43 CET; 23s ago Nov 11 17:48:43 sonostation-usb12-eth.ezono.net systemd[1]: Starting eZono Cyclades GUI. Nov 11 17:48:43 sonostation-usb12-eth.ezono.net systemd[1]: Reached target eZono Cyclades GUI. Also, DefaultDependencies=no is very unlikely to be what you need. I want to start ezono-cyclades-t_upn.path early as I can Also, /tmp/cyclades is subject to "predicatable paths in /tmp" attack. You should use a file in /run/. Zbyszek Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Path unit configuration starts early (DefaultDependencies=no)
On Mon, Nov 11, 2013 at 05:26:28PM +0100, Abdelghani Ouchabane wrote: > Hallo, > I have two configuration files: ezono-cyclades-t_upn.path & > ezono-cyclades-t_upn.service > > > Where: > > ezono-cyclades-t_upn.path : > > [Unit] > Description=ezono-cyclades-t_upn Service Spool > DefaultDependencies=no > Conflicts=shutdown.target > Before=shutdown.target > > [Path] > PathExists=/tmp/cyclades/start-ezono-cyclades-gui > > [Install] > WantedBy=ezono-cyclades.target > > > The problem is that by passing "DefaultDependencies=no" > ezono-cyclades-t_upn.service doesn't start after > /tmp/cyclades/start-ezono-cyclades-gui is created, even after all > other units run and I delete /tmp/cyclades/start-ezono-cyclades-gui > and create it again. > > Any idea please. Is ezono-cyclaed.target enabled? Also, DefaultDependencies=no is very unlikely to be what you need. Also, /tmp/cyclades is subject to "predicatable paths in /tmp" attack. You should use a file in /run/. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd + ExecStart + python script
On Mon, Nov 11, 2013 at 04:55:05PM +0100, Abdelghani Ouchabane wrote: > ExecStart=/usr/bin/python /opt/cyclades/bin/t_idl.pyo >|-1377 /bin/sh -c if [ ! -e > /home/x/taskconfig/screensaver ]; then /bin/mkdir -p > /home/x/taskconfig ;/bin/cp > /opt/cyclades/etc/taskconfig/screensaver > /home/x/taskconfig/screensaver ;fi ; > /bin/echo -n $BASHPID > /var/tmp/cyclades_services/IDL/pid ; > DISPLAY=:0 CYCLADES_ERR=IDL /opt/cyclades/bin/logger.sh -c > "/usr/bin/python /opt/cyclades/bin/t_idl.pyo" -p err -t IDL Those two don't correspond. Either you're starting the program directly, or through some shell scripts. It would help if you showed the two unit files. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Path unit configuration starts early (DefaultDependencies=no)
Hallo, I have two configuration files: ezono-cyclades-t_upn.path & ezono-cyclades-t_upn.service Where: ezono-cyclades-t_upn.path : [Unit] Description=ezono-cyclades-t_upn Service Spool DefaultDependencies=no Conflicts=shutdown.target Before=shutdown.target [Path] PathExists=/tmp/cyclades/start-ezono-cyclades-gui [Install] WantedBy=ezono-cyclades.target The problem is that by passing "DefaultDependencies=no" ezono-cyclades-t_upn.service doesn't start after /tmp/cyclades/start-ezono-cyclades-gui is created, even after all other units run and I delete /tmp/cyclades/start-ezono-cyclades-gui and create it again. Any idea please. Regards Abdelghani Log: ezono-cyclades-t_upn.service - ezono-cyclades-t_upn Service Loaded: loaded (/usr/lib/systemd/system/ezono-cyclades-t_upn.service; static) Active: inactive (dead) ezono-cyclades-t_upn.path - ezono-cyclades-t_upn Service Spool Loaded: loaded (/usr/lib/systemd/system/ezono-cyclades-t_upn.path; enabled) Active: active (waiting) since Mon 2013-11-11 17:19:30 CET; 4min 58s ago Nov 11 17:19:30 sonostation-usb12-eth.ezono.net systemd[1]: Starting ezono-cyclades-t_upn Service Spool. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd + ExecStart + python script
Hallo, I have two systemd files: ezono-cyclades-t_idl.path & ezono-cyclades-t_idl.service ( I am using systemd 204 ), xxx.path triggers .service And I am launching the main program as: ExecStart=/usr/bin/python /opt/cyclades/bin/t_idl.pyo Or ExecStart=/usr/bin/python /opt/cyclades/bin/t_idl.py The problem is that systemd is keeping starting ezono-cyclades-t_idl.service even after the unit starts. You can see the appearance of "Started ezono-cyclades-t_idl Service" many times in the below log. I tried many options but unfortunately I could not fix it. The problem here is that I have many other units and keeping starting this unit is causing problems for the other units. i doubt that the root of the problem is the python script!! It will be great if you can help me to find a solution. Many thanks in advance. Regards Abdelghani Here is the log: ezono-cyclades-t_idl.service - ezono-cyclades-t_idl Service Loaded: loaded (/usr/lib/systemd/system/ezono-cyclades-t_idl.service; static) Active: active (running) since Mon 2013-11-11 16:35:06 CET; 11min ago Main PID: 1377 (sh) CGroup: name=systemd:/system/ezono-cyclades-t_idl.service |-1377 /bin/sh -c if [ ! -e /home/x/taskconfig/screensaver ]; then /bin/mkdir -p /home/x/taskconfig ; /bin/cp /opt/cyclades/etc/taskconfig/screensaver /home/x/taskconfig/screensaver ;fi ;/bin/echo -n $BASHPID > /var/tmp/cyclades_services/IDL/pid ; DISPLAY=:0 CYCLADES_ERR=IDL /opt/cyclades/bin/logger.sh -c "/usr/bin/python /opt/cyclades/bin/t_idl.pyo" -p err -t IDL |-1433 /bin/sh -c if [ ! -e /home/x/taskconfig/screensaver ]; then /bin/mkdir -p /home/x/taskconfig ; /bin/cp /opt/cyclades/etc/taskconfig/screensaver /home/x/taskconfig/screensaver ;fi ;/bin/echo -n $BASHPID > /var/tmp/cyclades_services/IDL/pid ; DISPLAY=:0 CYCLADES_ERR=IDL /opt/cyclades/bin/logger.sh -c "/usr/bin/python /opt/cyclades/bin/t_idl.pyo" -p err -t IDL |-1550 /usr/bin/python /opt/cyclades/bin/t_idl.pyo `-1551 logger -p local4.err -t IDL -- Nov 11 16:35:12 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:12 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:12 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:14 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:14 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:14 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:14 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:16 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:18 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. Nov 11 16:35:32 sonostation-usb12-eth.ezono.net systemd[1]: Started ezono-cyclades-t_idl Service. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding an option to prefix date time when journal forwards messages to console
On Mon, Nov 11, 2013 at 4:24 PM, Umut Tezduyar Lindskog wrote: > We think being able to see the journal message timestamps on console is > important. A locked up embedded system where we only have the output of > console would be even more useful if we were to know when things went wrong. > For this reason, we would like to ask: is it ok if we have such feature in > journald.conf? The kernel controls this behaviour with the boolean: /sys/module/printk/parameters/time maybe we could read just that? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Adding an option to prefix date time when journal forwards messages to console
Hi, We think being able to see the journal message timestamps on console is important. A locked up embedded system where we only have the output of console would be even more useful if we were to know when things went wrong. For this reason, we would like to ask: is it ok if we have such feature in journald.conf? Thanks, Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] udev: add exclusive event filter
On Mon, Nov 11, 2013 at 3:13 PM, Kyungmin Park wrote: > On Mon, Nov 11, 2013 at 10:43 PM, Kay Sievers wrote: >>> I want to skip this kind of events just after retrieving from netlink >>> without worker fork. >>> This patch will filter-out(I could not find suitable vocabulary because >>> of we already using "filter".) subsystem:devtype events what be listed >>> in udev.conf. If we want to skip whole of subsystem then subsystem can >>> only be specified. >> >> Please fix your kernel, driver, subsystem instead. Uevents were never >> meant to carry higher-frequent events, it's justy not what they should >> be used for. > > Here's real use cases for brightness. Here is just the result of a completely misguided use of uevents. :) > now most mobile phone has ambient Light Sensors and it changes > brightness according lux. > it means it changes backlight brightness by just writing backlight subsystem. > in backlight subsystem, after writing sysfs node, it generates uevent. Which is nothing but a terribly broken driver behavior. Using uevents for such changes makes zero sense, the kernel should be fixed instead to stop this nonsense. > usually there's no user to use this backlight changes. but it forks > udev worker threads and it takes about 5ms. > the main problem is that it hurts other process activities. Sure, I see the problem, but we do not want to work around such brokenness in userspace. > if you mean modify kernel driver, subsystem, we have to ignore below codes. > > Are there any other way to avoid these udev worker thread? No, please fix the problem where it is caused. Uevents are for the major, low-frequent, global device state-changes, not for carrying-out any sort of measurement data. Subsystems which need that should use other facilities like poll()-able sysfs file or any other subscription-based, client-tracking interface which does not cause overhead if it isn't used. Uevents are not the right thing to use here, and upstream udev should not paper-over broken kernel subsystems. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] udev: add exclusive event filter
On Mon, Nov 11, 2013 at 10:43 PM, Kay Sievers wrote:
> On Mon, Nov 11, 2013 at 8:12 AM, WaLyong Cho wrote:
>> Previously, ignore_device option had existed until udev 147. But that
>> was removed after below commit.
>>
>> cdae488a3fbca5a61b3f8ea0651730cfa2da9cb0
>>
>> remove "ignore_device"
>> There is no way to ignore an event these days. Libudev events can
>> not be suppressed. It only prevents RUN keys from being executed,
>> which results in an inconsistent behavior in current setups.
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdae488a3fbca5a61b3f8ea0651730cfa2da9cb0
>>
>>
>> In mobile(maybe also embedded) world, power and memory management are
>> big issue. That can not be compromised. If there are no tasks who
>> receive such uevents from udev monitor(not kernel monitor) then the
>> uevents are useless. Each uevent will may cause each fork() if there is
>> no idle worker.
>>
>> In our system, there is a special daemon who directly linked with kernel
>> monitor. (That is similar with system server of android.) He receive
>> event data from kernel monitor. And some of events are only treated by
>> him. Especially, backlight and power_supply(battery) events are. In
>> every change state of LCD, backlight events were occurred. In desktop
>> environment, this event may be occurred one or twice per hour. (Sure, it
>> can configurable.) And, in every battery percentage changing,
>> power_supply events were happen. (I couldn't see this on my fedora when
>> using ac-power. I'm not sure it because of full charged stated.) Anyway,
>> both of them are more frequently happen in mobile world.
>> In our worst case, a uevent(a kind of thermistor) was happen each 10
>> second. If udev is in idle state, udev will fork to process that event.
>> After processing(may be 3 sec), the worker will be terminated. There are
>> no workers during 7 seconds. And worker will be forked again by the uevent.
>> Yeah, it is a terrible repetition of our system.
>>
>> I want to skip this kind of events just after retrieving from netlink
>> without worker fork.
>> This patch will filter-out(I could not find suitable vocabulary because
>> of we already using "filter".) subsystem:devtype events what be listed
>> in udev.conf. If we want to skip whole of subsystem then subsystem can
>> only be specified.
>
> Please fix your kernel, driver, subsystem instead. Uevents were never
> meant to carry higher-frequent events, it's justy not what they should
> be used for.
Here's real use cases for brightness.
now most mobile phone has ambient Light Sensors and it changes
brightness according lux.
it means it changes backlight brightness by just writing backlight subsystem.
in backlight subsystem, after writing sysfs node, it generates uevent.
usually there's no user to use this backlight changes. but it forks
udev worker threads and it takes about 5ms.
the main problem is that it hurts other process activities.
if you mean modify kernel driver, subsystem, we have to ignore below codes.
Are there any other way to avoid these udev worker thread?
85 static void backlight_generate_event(struct backlight_device *bd,
86 enum backlight_update_reason reason)
87 {
88 char *envp[2];
89
90 switch (reason) {
91 case BACKLIGHT_UPDATE_SYSFS:
92 envp[0] = "SOURCE=sysfs";
93 break;
94 case BACKLIGHT_UPDATE_HOTKEY:
95 envp[0] = "SOURCE=hotkey";
96 break;
97 default:
98 envp[0] = "SOURCE=unknown";
99 break;
100 }
101 envp[1] = NULL;
102 kobject_uevent_env(&bd->dev.kobj, KOBJ_CHANGE, envp);
103 sysfs_notify(&bd->dev.kobj, NULL, "actual_brightness");
104 }
http://git.infradead.org/linux-2.6.git/blob/HEAD:/drivers/video/backlight/backlight.c
Thank you,
Kyungmin Park
>
> And udev is not meant to filter or suppress any events from the
> kernel, it's too late in the game, and people will only mis-use things
> here, to paper-over broken kernel drivers. Upstream udev better does
> not want to provide such a facility.
>
> Thanks,
> Kay
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] udev: add exclusive event filter
On Mon, Nov 11, 2013 at 8:12 AM, WaLyong Cho wrote: > Previously, ignore_device option had existed until udev 147. But that > was removed after below commit. > > cdae488a3fbca5a61b3f8ea0651730cfa2da9cb0 > > remove "ignore_device" > There is no way to ignore an event these days. Libudev events can > not be suppressed. It only prevents RUN keys from being executed, > which results in an inconsistent behavior in current setups. > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdae488a3fbca5a61b3f8ea0651730cfa2da9cb0 > > > In mobile(maybe also embedded) world, power and memory management are > big issue. That can not be compromised. If there are no tasks who > receive such uevents from udev monitor(not kernel monitor) then the > uevents are useless. Each uevent will may cause each fork() if there is > no idle worker. > > In our system, there is a special daemon who directly linked with kernel > monitor. (That is similar with system server of android.) He receive > event data from kernel monitor. And some of events are only treated by > him. Especially, backlight and power_supply(battery) events are. In > every change state of LCD, backlight events were occurred. In desktop > environment, this event may be occurred one or twice per hour. (Sure, it > can configurable.) And, in every battery percentage changing, > power_supply events were happen. (I couldn't see this on my fedora when > using ac-power. I'm not sure it because of full charged stated.) Anyway, > both of them are more frequently happen in mobile world. > In our worst case, a uevent(a kind of thermistor) was happen each 10 > second. If udev is in idle state, udev will fork to process that event. > After processing(may be 3 sec), the worker will be terminated. There are > no workers during 7 seconds. And worker will be forked again by the uevent. > Yeah, it is a terrible repetition of our system. > > I want to skip this kind of events just after retrieving from netlink > without worker fork. > This patch will filter-out(I could not find suitable vocabulary because > of we already using "filter".) subsystem:devtype events what be listed > in udev.conf. If we want to skip whole of subsystem then subsystem can > only be specified. Please fix your kernel, driver, subsystem instead. Uevents were never meant to carry higher-frequent events, it's justy not what they should be used for. And udev is not meant to filter or suppress any events from the kernel, it's too late in the game, and people will only mis-use things here, to paper-over broken kernel drivers. Upstream udev better does not want to provide such a facility. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] tmpfiles: skip the path entirely if configured as type x
On Mon, 11.11.13 13:19, Michal Sekletar (msekl...@redhat.com) wrote: > > So I still don't get the problem you are trying to point out. Can you > > give a minimal example where the problem manifests? Maybe I grok it > > then... > > > > Please consider following configuration and steps to reproduce: > > *** /etc/tmpfiles.d/test.conf *** > d /tmp/testdir 0755 lennart lennart 1s > x /tmp/testdir Ahum. So, either this should generate an error, as there are two lines for the same directory, and we shouldn't allow that. Or we declare lines of type "x" and "d" mergable and then merge them together. However, I am pretty sure we should just generate an error here... 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/3] tmpfiles: skip the path entirely if configured as type x
On Sun, Nov 10, 2013 at 11:13:57PM +0100, Lennart Poettering wrote: > On Fri, 08.11.13 14:36, Michal Sekletar (msekl...@redhat.com) wrote: > > > > > On Thu, Nov 07, 2013 at 10:39:19PM +0100, Lennart Poettering wrote: > > > On Wed, 06.11.13 11:18, Michal Sekletar (msekl...@redhat.com) wrote: > > > > > > > Type x in tmpfiles configuration accepts shell style globs instead of > > > > normal > > > > paths. If user uses normal path he might expect that the path will be > > > > left > > > > untouched. However this is not the case for directories and content of > > > > the > > > > directory will be cleaned according to the Age parameter, we should > > > > rather skip > > > > the path entirely in such case. > > > > > > > Hi Lennart, > > > > > Not sure I follow. dir_cleanup() already skips all items listed in the > > > glob hashmap anyway, no? What does your patch add on top of that? > > > > In dir_cleanup() we skip if there is an item configured for the path or it > > matches the glob, however we are doing it on the subpaths of currently > > processed > > directory. This won't work in the case mentioned in the commit message. If > > user > > wants to exclude path from cleanup entirely he has to use x /path/*, this > > way > > all subpaths match the glob. In case of x /path/ no subpath matches such > > glob > > and we remove them, hence checking explicitly beforehand. > > Hmm, still not following... Hi Lennart, > > When we iterate through a directory tree to clean things up we check if > the path in we currently look at matches any glob or whether there is > any line defined for it at all. True, but in the case I described in previous email there is no specific item for subpaths of the currently processed directory nor subpaths match any glob since user uses x /some/path in the configuration. If user would have used x /some/path/* then we match subpaths of /some/path against such glob and correctly skip them. > If so, we skip the entry (and do not > descend further into it!). This is in the two if blocks that carry the > "Is there an item configured for this path?" comment? Well, we open dir and then call readdir() in a while loop, we skip ., .. and then we process process directory content. In case there is a matching glob or specific item configured we call continue to process next file in the directory. This is my interpretation of what is happening, if it doesn't make any sense to you then I guess that I am terribly wrong. > > So I still don't get the problem you are trying to point out. Can you > give a minimal example where the problem manifests? Maybe I grok it > then... > Please consider following configuration and steps to reproduce: *** /etc/tmpfiles.d/test.conf *** d /tmp/testdir 0755 lennart lennart 1s x /tmp/testdir # systemd-tmpfiles --create test.conf $ mkdir /tmp/testdir/a $ mkdir /tmp/testdir/b # systemd-tmpfiles --clean test.conf $ ls -l Before applying a patch and following steps to reproduce you should end up with empty /tmp/testdir, i.e. manually created directories a and b are removed. This is not the case after applying the patch, thus making things more understandable to admin since in both cases he used configuration x /tmp/testdir but in the former case is content deleted. > Thanks! Hope that helps! Michal > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
