Age | Commit message (Collapse) | Author |
|
Rather than catch all, is now limited to UnicodeDecodeError
|
|
|
|
iternext now checks for error from get_next, and changed a DECREF to
XDECREF rather than NULL check
|
|
|
|
|
|
|
|
|
|
|
|
|
|
python code now takes care of multiple matches
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Build instructions:
make
make DESTIDIR=/tmp/... install
make DESTIDIR=/tmp/... sphinx-html sphinx-man sphinx-epub ...
|
|
|
|
|
|
uuid.UUIDs are utilized to hold UUID values.
|
|
Should be no functional change.
|
|
Occasionally people report problem with reboot/poweroff operations hanging in
the middle. One known cause is when a new transaction to start a unit is
enqueued while the shutdown is going on. The start of the unit conflicts with
the shutdown jobs, so they get cancelled. The failure case can be quite unpleasant,
becase getty and sshd may already be stopped.
Fix it by using irreversible jobs for shutdown (reboot/poweroff/...) actions.
This applies to commands like "reboot", "telinit 6", "systemctl reboot". Should
someone desire to use reversible jobs, they can say "systemctl start reboot.target".`
|
|
Add a new job mode: replace-irreversibly. Jobs enqueued using this mode
cannot be implicitly canceled by later enqueued conflicting jobs.
They can however still be canceled with an explicit "systemctl cancel"
call.
|
|
"systemctl default" should behave identically to "telinit N" (where N is the
corresponding runlevel target number), therefore it should use isolate job mode
too.
|
|
Documentation states that 0 is correct, and all other
similar functions return 0 on success.
Pointed-out-by: Steven Hiscocks <steven-systemd@hiscocks.me.uk>
|
|
Use /sysroot instead of /new_root to mount the real root in the
initramfs.
|
|
tests for:
test_parse_pid
test_parse_uid
test_safe_atolli
test_safe_atod
|
|
cleanup
|
|
New OOM check patch:
I do assert_se() before variable is used to do correct check.
|
|
|
|
|
|
|
|
|
|
On Thu, Feb 7, 2013 at 3:52 PM, Robert Milasan <rmilasan@suse.com> wrote:
> Hi, seems that using some strange usb devices with really bogus serial
> numbers usb_id creates links with junk strings in it:
>
> /dev/disk/by-id/usb-TSSTcorp_BDDVDW_SE-506AB_㡒䍌䜶䉗ぁㄴ㌴†ँ-0:0
>
> Initially was believed that usb_id is to blame, then the kernel, but it
> turns out that really the usb cd/dvd drive has this bogus serial number:
>
> output from dmesg:
> [ 538.200160] usb 1-2: new high-speed USB device number 5 using
> ehci_hcd [ 538.335067] usb 1-2: New USB device found, idVendor=0e8d,
> idProduct=1956 [ 538.335080] usb 1-2: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3 [ 538.335089] usb 1-2: Product: MT1956
> [ 538.335097] usb 1-2: Manufacturer: MediaTek Inc
> [ 538.335105] usb 1-2: SerialNumber:
> \xffffffe3\xffffffa1\xffffff92\xffffffe4\xffffff8d\xffffff8c ...
> [ 538.337540] scsi6 : usb-storage 1-2:1.0 [ 539.341385] scsi 6:0:0:0:
> CD-ROM TSSTcorp BDDVDW SE-506AB TS00 PQ: 0 ANSI: 0
> [ 539.354240] sr0: scsi3-mmc drive: 0x/24x writer dvd-ram cd/rw
> xa/form2 cdda tray [ 539.354777] sr 6:0:0:0: Attached scsi CD-ROM sr0
> [ 539.355122] sr 6:0:0:0: Attached scsi generic sg2 type 5
|
|
|
|
|
|
|
|
Turning off filtering with --filter is just too confusing.
Config option "Filter" doesn't have to be changed, here
"Filter=yes" already meant to filter.
|
|
|
|
|
|
|
|
This makes 'status' behave like 'list-units':
systemctl status -> status of all units
systemctl -t error status -> status of error units
systemctl -t mount status -> etc.
|
|
It is not really necessary to have a hard requirement dependency on
systemd-journald.socket in almost every unit. The socket gets pulled
into boot via at least two ways:
sockets.target -> systemd-journald.socket
sysinit.target -> systemd-journald.service -> systemd-journald.socket
So just assume something pulled the socket in and drop the automatic
requirement dependencies on it.
"systemctl stop systemd-journald.socket" will now not take the whole
system down with it.
|
|
journald is supposed to work. Failure to connect to its socket implies
losing messages. It should be a very unusual event. Log the failure with
LOG_CRIT.
Just because this unit's stdout/stderr failed to connect to the journal
does not necessarily mean that we shouldn't try to log the failure using
a structured entry, so let's use log_struct_unit.
|