Chapter 3. Configuring the Date and Time

Modern operating systems distinguish between the following two types of clocks:
  • real-time clock (RTC), commonly referred to as a hardware clock, (typically an integrated circuit on the system board) that is completely independent of the current state of the operating system and runs even when the computer is shut down.
  • system clock, also known as a software clock, that is maintained by the kernel and its initial value is based on the real-time clock. Once the system is booted and the system clock is initialized, the system clock is completely independent of the real-time clock.
The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST). The real-time clock can use either UTC or local time. UTC is recommended.
Fedora 25 offers three command line tools that can be used to configure and display information about the system date and time: the timedatectl utility, which is new in Fedora 25 and is part of systemd; the traditional date command; and the hwclock utility for accessing the hardware clock.

3.1. Using the timedatectl Command

The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock. You can use this tool to change the current date and time, set the time zone, or enable automatic synchronization of the system clock with a remote server.
For information on how to display the current date and time in a custom format, see also Section 3.2, “Using the date Command”.

3.1.1. Displaying the Current Date and Time

To display the current date and time along with detailed information about the configuration of the system and hardware clock, run the timedatectl command with no additional command line options:
timedatectl
This displays the local and universal time, the currently used time zone, the status of the Network Time Protocol (NTP) configuration, and additional information related to DST.
Example 3.1. Displaying the Current Date and Time
The following is an example output of the timedatectl command on a system that does not use NTP to synchronize the system clock with a remote server:
~]$ timedatectl
      Local time: Mon 2013-09-16 19:30:24 CEST
  Universal time: Mon 2013-09-16 17:30:24 UTC
        Timezone: Europe/Prague (CEST, +0200)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET

3.1.2. Changing the Current Time

To change the current time, type the following at a shell prompt as root:
timedatectl set-time HH:MM:SS
Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form.
This command updates both the system time and the hardware clock. The result it is similar to using both the date --setand hwclock --systohc commands.
The command will fail if an NTP service is enabled. See Section 3.1.5, “Synchronizing the System Clock with a Remote Server” to temporally disable the service.
Example 3.2. Changing the Current Time
To change the current time to 11:26 p.m., run the following command as root:
~]# timedatectl set-time 23:26:00

By default, the system is configured to use UTC. To configure your system to maintain the clock in the local time, run the timedatectl command with the set-local-rtc option as root:
timedatectl set-local-rtc boolean
To configure your system to maintain the clock in the local time, replace boolean with yes (or, alternatively, ytruet, or 1). To configure the system to use UTC, replace boolean with no (or, alternatively, nfalsef, or 0). The default option is no.

3.1.3. Changing the Current Date

To change the current date, type the following at a shell prompt as root:
timedatectl set-time YYYY-MM-DD
Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month.
Note that changing the date without specifying the current time results in setting the time to 00:00:00.
Example 3.3. Changing the Current Date
To change the current date to 2 June 2013 and keep the current time (11:26 p.m.), run the following command as root:
~]# timedatectl set-time "2013-06-02 23:26:00"

3.1.4. Changing the Time Zone

To list all available time zones, type the following at a shell prompt:
timedatectl list-timezones
To change the currently used time zone, type as root:
timedatectl set-timezone time_zone
Replace time_zone with any of the values listed by the timedatectl list-timezones command.
Example 3.4. Changing the Time Zone
To identify which time zone is closest to your present location, use the timedatectl command with the list-timezones command line option. For example, to list all available time zones in Europe, type:
~]# timedatectl list-timezones | grep Europe
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belgrade
Europe/Berlin
Europe/Bratislava
To change the time zone to Europe/Prague, type as root:
~]# timedatectl set-timezone Europe/Prague

3.1.5. Synchronizing the System Clock with a Remote Server

As opposed to the manual adjustments described in the previous sections, the timedatectl command also allows you to enable automatic synchronization of your system clock with a group of remote servers using the NTP protocol. Enabling NTP enables the chronyd or ntpd service, depending on which of them is installed.
The NTP service can be enabled and disabled using a command as follows:
timedatectl set-ntp boolean
To enable your system to synchronize the system clock with a remote NTP server, replace boolean with yes (the default option). To disable this feature, replace boolean with no.
Example 3.5. Synchronizing the System Clock with a Remote Server
To enable automatic synchronization of the system clock with a remote server, type:
~]# timedatectl set-ntp yes
The command will fail if an NTP service is not installed. See Section 14.3.1, “Installing chrony” for more information.



source - https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/ch-Configuring_the_Date_and_Time.html


저작자 표시
신고

'System > Linux' 카테고리의 다른 글

fedora - timedatectl  (0) 2016.12.17
linux - LWP  (0) 2016.12.16
linux - dnf broken  (0) 2016.12.04
linux - chmod  (0) 2016.09.03
linux - SNMP 설정(CentOS 5.6)  (0) 2016.08.25
fedora - Adding or Removing a application launcher  (0) 2016.06.26
Posted by linuxism


Gradle 3.2.1 is now available

This bug-fix release candidate addresses uncaught regressions in v3.2.0 in the Gradle wrapper.

Fixed issues:
GRADLE-3582: Gradle wrapper fails to escape arguments with nested quotes
GRADLE-3583: Newlines in environment variables used by the wrapper breaks application plugin shell script

If no further regressions are reported, a final release will follow in the next week.

Upgrade Instructions

Switch your build to use Gradle 3.2.1 by updating your wrapper properties:

./gradlew wrapper --gradle-version=3.2.1

Standalone downloads are available at https://gradle.org/gradle-download.

Heads up: In addition, if you generated this wrapper with Gradle 3.2, re-run ./gradlew wrapper to avoid a misconfigured wrapper script.

Reporting Problems

If you find a problem with Gradle 3.2.1, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.



source - https://discuss.gradle.org/t/how-to-deploy-jar-using-uploadarchives-for-war-project/11370








Gradle Wrapper


Most tools require installation on your computer before you can use them. If the installation is easy, you may think that’s fine. But it can be an unnecessary burden on the users of the build. Equally importantly, will the user install the right version of the tool for the build? What if they’re building an old version of the software?

The Gradle Wrapper (henceforth referred to as the “Wrapper”) solves both these problems and is the preferred way of starting a Gradle build.

5.1. Executing a build with the Wrapper

If a Gradle project has set up the Wrapper (and we recommend all projects do so), you can execute the build using one of the following commands from the root of the project:

  • ./gradlew <task> (on Unix-like platforms such as Linux and Mac OS X)

  • gradlew <task> (on Windows using the gradlew.bat batch file)

Each Wrapper is tied to a specific version of Gradle, so when you first run one of the commands above for a given Gradle version, it will download the corresponding Gradle distribution and use it to execute the build.

IDEs

When importing a Gradle project via its wrapper, your IDE may ask to use the Gradle 'all' distribution. This is perfectly fine and helps the IDE provide code completion for the build files.

Not only does this mean that you don’t have to manually install Gradle yourself, but you are also sure to use the version of Gradle that the build is designed for. This makes your historical builds more reliable. Just use the appropriate syntax from above whenever you see a command line starting with gradle ... in the user guide, on Stack Overflow, in articles or wherever.

For completeness sake, and to ensure you don’t delete any important files, here are the files and directories in a Gradle project that make up the Wrapper:

  • gradlew (Unix Shell script)

  • gradlew.bat (Windows batch file)

  • gradle/wrapper/gradle-wrapper.jar (Wrapper JAR)

  • gradle/wrapper/gradle-wrapper.properties (Wrapper properties)

If you’re wondering where the Gradle distributions are stored, you’ll find them in your user home directory under $USER_HOME/.gradle/wrapper/dists.

5.2. Adding the Wrapper to a project

The Wrapper is something you should check into version control. By distributing the Wrapper with your project, anyone can work with it without needing to install Gradle beforehand. Even better, users of the build are guaranteed to use the version of Gradle that the build was designed to work with. Of course, this is also great forcontinuous integration servers (i.e. servers that regularly build your project) as it requires no configuration on the server.

You install the Wrapper into your project by running the wrapper task. (This task is always available, even if you don't add it to your build). To specify a Gradle version use --gradle-version on the command-line. By default, the Wrapper will use a bin distribution. This is the smallest Gradle distribution. Some tools, like Android Studio and Intellij IDEA, provide additional context information when used with the all distribution. You may select a different Gradle distribution type by using --distribution-type. You can also set the URL to download Gradle from directly via --gradle-distribution-url. If no version or distribution URL is specified, the Wrapper will be configured to use the gradle version the wrapper task is executed with. So if you run the wrapper task with Gradle 2.4, then the Wrapper configuration will default to version 2.4.

Example 5.1. Running the Wrapper task

Output of gradle wrapper --gradle-version 2.0

> gradle wrapper --gradle-version 2.0
:wrapper

BUILD SUCCESSFUL

Total time: 1 secs

The Wrapper can be further customized by adding and configuring a Wrapper task in your build script, and then executing it.

Example 5.2. Wrapper task

build.gradle

task wrapper(type: Wrapper) {
    gradleVersion = '2.0'
}

After such an execution you find the following new or updated files in your project directory (in case the default configuration of the Wrapper task is used).

Example 5.3. Wrapper generated files

Build layout

simple/
  gradlew
  gradlew.bat
  gradle/wrapper/
    gradle-wrapper.jar
    gradle-wrapper.properties

All of these files should be submitted to your version control system. This only needs to be done once. After these files have been added to the project, the project should then be built with the added gradlew command. The gradlew command can be used exactly the same way as the gradle command.

If you want to switch to a new version of Gradle you don't need to rerun the wrapper task. It is good enough to change the respective entry in the gradle-wrapper.properties file, but if you want to take advantage of new functionality in the Gradle wrapper, then you would need to regenerate the wrapper files.

5.3. Configuration

If you run Gradle with gradlew, the Wrapper checks if a Gradle distribution for the Wrapper is available. If so, it delegates to the gradle command of this distribution with all the arguments passed originally to the gradlew command. If it didn't find a Gradle distribution, it will download it first.

When you configure the Wrapper task, you can specify the Gradle version you wish to use. The gradlew command will download the appropriate distribution from the Gradle repository. Alternatively, you can specify the download URL of the Gradle distribution. The gradlew command will use this URL to download the distribution. If you specified neither a Gradle version nor download URL, the gradlew command will download whichever version of Gradle was used to generate the Wrapper files.

For the details on how to configure the Wrapper, see the Wrapper class in the API documentation.

If you don't want any download to happen when your project is built via gradlew, simply add the Gradle distribution zip to your version control at the location specified by your Wrapper configuration. A relative URL is supported - you can specify a distribution file relative to the location of gradle-wrapper.properties file.

If you build via the Wrapper, any existing Gradle distribution installed on the machine is ignored.

5.4. Authenticated Gradle distribution download

Security Warning

HTTP Basic Authentication should only be used with HTTPS URLs and not plain HTTP ones. With Basic Authentication, the user credentials are sent in clear text.

The Gradle Wrapper can download Gradle distributions from servers using HTTP Basic Authentication. This enables you to host the Gradle distribution on a private protected server. You can specify a username and password in two different ways depending on your use case: as system properties or directly embedded in the distributionUrl. Credentials in system properties take precedence over the ones embedded in distributionUrl.

Using system properties can be done in the .gradle/gradle.properties file in the user's home directory, or by other means, see Section 12.1, “Configuring the build environment via gradle.properties”.

Example 5.4. Specifying the HTTP Basic Authentication credentials using system properties

gradle.properties

systemProp.gradle.wrapperUser=username
systemProp.gradle.wrapperPassword=password

Embedding credentials in the distributionUrl in the gradle/wrapper/gradle-wrapper.properties file also works. Please note that this file is to be committed into your source control system. Shared credentials embedded in distributionUrl should only be used in a controlled environment.

Example 5.5. Specifying the HTTP Basic Authentication credentials in distributionUrl

gradle-wrapper.properties

distributionUrl=https://username:password@somehost/path/to/gradle-distribution.zip

This can be used in conjunction with a proxy, authenticated or not. See Section 12.3, “Accessing the web via a proxy” for more information on how to configure the Wrapperto use a proxy.

5.5. Verification of downloaded Gradle distributions

The Gradle Wrapper allows for verification of the downloaded Gradle distribution via SHA-256 hash sum comparison. This increases security against targeted attacks by preventing a man-in-the-middle attacker from tampering with the downloaded Gradle distribution.

To enable this feature you'll want to first calculate the SHA-256 hash of a known Gradle distribution. You can generate a SHA-256 hash from Linux and OSX or Windows (via Cygwin) with the shasum command.

Example 5.6. Generating a SHA-256 hash

> shasum -a 256 gradle-2.4-all.zip
371cb9fbebbe9880d147f59bab36d61eee122854ef8c9ee1ecf12b82368bcf10  gradle-2.4-all.zip

Add the returned hash sum to the gradle-wrapper.properties using the distributionSha256Sum property.

Example 5.7. Configuring SHA-256 checksum verification

gradle-wrapper.properties

distributionSha256Sum=371cb9fbebbe9880d147f59bab36d61eee122854ef8c9ee1ecf12b82368bcf10

5.6. Unix file permissions

The Wrapper task adds appropriate file permissions to allow the execution of the gradlew *NIX command. Subversion preserves this file permission. We are not sure how other version control systems deal with this. What should always work is to execute “sh gradlew”.



source - https://docs.gradle.org/current/userguide/gradle_wrapper.html








Gradle Wrapper

명령행을 통한 Wrapper 기본 설정

Gradle 3.1 버전에 all 타입으로 wrapper 설정 생성.

gradle wrapper --gradle-version 3.1 --distribution-type all

distribution-type은 Gradle 3.x 부터 가능.

기본 설정

  • 더이상 불필요.
  • build.gradle
    task wrapper(type: Wrapper) {
        gradleVersion = '1.6' // 원하는 Gradle 버전 명시
    }
  • gradle wrapper를 한 번실행해 주면 gradle/wrapper 디렉토리가 생성되고 래퍼 jar 들이 복사된다.
  • 이 상태 그대로를 VCS에 올려서 공유하면 다른 개발자들은 gradlew 혹은 gradlew.bat 명령으로 Gradle 작업을 수행하면 된다.
  • *Nix 계열에서는 gradlew 파일에 실행 권한이 없으므로 항상 sh gradlew 옵션들 형태로 실행해야 한다.

세부 설정

  • gradlew[.bat] 파일에서 DEFAULT_JVM_OPTS를 편집하여 기본 JVM 옵션을 설정할 수 있다.
  • gradle/wrapper/gradle-wrapper.properties 파일에서 distributionUrl 을 프라퍼티 파일이 있는 디렉토리에 대해 상대 경로로 지정하면 URL에서 다운로드 받지 않고 저장된 파일을 사용할 수 있다.

gradlew 자동 찾아 실행하는 스크립트

  • Linux에서 현재 디렉토리를 포함하여 자기 위의 디렉토리를 자동으로 탐색하여 gradlew 명령을 찾고 이를 실행해주는 스크립트.
  • 파일명 : gw
    #!/bin/bash
    current_dir=`pwd`
    while [ "$current_dir" != "/" ]
    do
        if [ -f "$current_dir/gradlew" ]
        then
            break;
        fi
        current_dir=`dirname "$current_dir"`
    done
     
    if [ "$current_dir" != "/" ]
    then
        bash "$current_dir/gradlew" "$@"
    else
        echo "No gradlew file exists."
    fi
  • 실행예
    # 현재 디렉토리가 ~/project/module_1 이고, gradlew 는 project에 있을 때
    gw dependencies
     
    # 위 명령은 자동으로 project/gradlew dependencies를 현재 디렉토리에서 실행한다.
    # 따라서 실제 실행 결과는 다음과 같다.
    ~/project/gradlew :module_1:dependencies



source - http://kwonnam.pe.kr/wiki/gradle/wrapper


저작자 표시
신고

'IDE & Build > Gradle' 카테고리의 다른 글

gradle - gradlew wrapper  (0) 2016.12.17
gradle - gradlew build  (0) 2016.12.14
gradle - Using the Gradle build system in the Eclipse IDE - Tutorial  (0) 2016.12.03
gradle - 설치  (1) 2012.11.05
maven 대신 gradle  (0) 2012.10.16
Posted by linuxism

linux - LWP

System/Linux 2016.12.16 08:13


In computer operating systems, a light-weight process (LWP) is a means of achieving multitasking. In the traditional meaning of the term, as used in Unix System V and Solaris, a LWP runs in user space on top of a single kernel threadand shares its address space and system resources with other LWPs within the same process. Multiple user level threads, managed by a thread library, can be placed on top of one or many LWPs - allowing multitasking to be done at the user level, which can have some performance benefits.[1]

In some operating systems there is no separate LWP layer between kernel threads and user threads. This means that user threads are implemented directly on top of kernel threads. In those contexts, the term "light-weight process" typically refers to kernel threads and the term "threads" can refer to user threads.[2] On Linux, user threads are implemented by allowing certain processes to share resources, which sometimes leads to these processes to be called "light weight processes".[3][4] Similarly, in SunOS version 4 onwards (prior to Solaris) "light weight process" referred to user threads.[1]

Kernel threads[edit source]

Kernel threads are handled entirely by the kernel. They need not be associated with a process; a kernel can create them whenever it needs to perform a particular task. Kernel threads cannot execute in user mode. LWPs (in systems where they are a separate layer) bind to kernel threads and provide a user-level context. This includes a link to the shared resources of the process to which the LWP belongs. When a LWP is suspended, it needs to store its user-level registers until it resumes, and the underlying kernel thread must also store its own kernel-level registers.

Performance[edit source]

LWPs are slower and more expensive to create than user threads. Whenever an LWP is created a system call must first be made to create a corresponding kernel thread, causing a switch to kernel mode. These mode switches would typically involve copying parameters between kernel and user space, also the kernel may need to have extra steps to verify the parameters to check for invalid behavior. A context switch between LWPs means that the LWP that is being pre-empted has to save its registers, then go into kernel mode for the kernel thread to save its registers, and the LWP that is being scheduled must restore the kernel and user registers separately also.[1]

For this reason, some user level thread libraries allow multiple user threads to be implemented on top of LWPs. User threads can be created, destroyed, synchronized and switched between entirely in user space without system calls and switches into kernel mode. This provides a significant performance improvement in thread creation time and context switches.[1] However, there are difficulties in implementing a user level thread scheduler that works well together with the kernel.

LWPs were introduced by SUN Micro Systems.[citation needed]

Scheduler activation[edit source]

While the user threading library will schedule user threads, the kernel will schedule the underlying LWPs. Without coordination between the kernel and the thread library the kernel can make sub-optimal scheduling decisions. Further, it is possible for cases of deadlock to occur when user threads distributed over several LWPs try to acquire the same resources that are used by another user thread that is not currently running.[1]

One solution to this problem is scheduler activation. This is a method for the kernel and the thread library to cooperate. The kernel notifies the thread library's scheduler about certain events (such as when a thread is about to block) and the thread library can make a decision on what action to take. The notification call from the kernel is called an "upcall".

A user level library has no control over the underlying mechanism, it only receives notifications from the kernel and schedules user threads onto available LWPs, not processors. The kernel's scheduler then decides how to schedule the LWPs onto the processors. This means that LWPs can be seen by the thread library as "virtual processors".[5]

Supporting operating systems[edit source]

Solaris has implemented a separate LWP layer since version 2.2. Prior to version 9, Solaris allowed a many-to-many mapping between LWPs and user threads. However, this was retired due to the complexities it introduced and performance improvements to the kernel scheduler.[1][6]

UNIX System V and its modern derivatives IRIXSCO OpenServerHP-UX and IBM AIX allow a many-to-many mapping between user threads and LWPs.[5][7]

See also[edit source]



source - https://en.wikipedia.org/wiki/Light-weight_process



저작자 표시
신고

'System > Linux' 카테고리의 다른 글

fedora - timedatectl  (0) 2016.12.17
linux - LWP  (0) 2016.12.16
linux - dnf broken  (0) 2016.12.04
linux - chmod  (0) 2016.09.03
linux - SNMP 설정(CentOS 5.6)  (0) 2016.08.25
fedora - Adding or Removing a application launcher  (0) 2016.06.26
Posted by linuxism


티스토리 툴바